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DEFENSE  SCIENCE  Octobei  17,  1996 

BOARD 

MEMORANDUM  FOR  UNDER  SECRETARY  OF  DEFENSE  (ACQUISITION  AND 

TECHNOLOGY) 

SUBJECT:  Report  of  the  Defense  Science  Board  (DSB)  Task  Force  on  Military 
Personnel  Information  Management 


I  am  pleased  to  forward  the  final  report  of  the  DSB  Task  Force  on  Military 
Personnel  Information  Management,  which  was  chaired  by  Dr.  Alan  Salisbury.  The  Task 
Force  members  and  advisors  unanimously  concluded  that  the  Department  should  develop 
and  implement  a  single,  fully  integrated  military  personnel  and  pay  system  to  be  used  by 
all  components.  The  report  further  provides  supporting  recommendations  on  functional 
and  technical  criteria  for  the  objective  system;  a  transition  strategy;  and  a  management 
structure.  It  also  recommends  assignment  of  responsibilities  for  implementation. 

In  brief,  the  Task  Force  recommends: 

•  a  single  all-service  and  all-component,  fully  integrated  personnel  and  pay 
system,  with  conunon  core  software  built  on  a  COTS  base  (or  a  modified- 
COTS  system),  with  an  Initial  Operating  Capability  of  2001  or  earlier; 

•  an  acceleration  of  the  process  initiated  by  the  Personnel  and  Readiness 
Military  Personnel  Management  Joint  Working  Group  to  define  joint 
functional  requirements,  with  full  participation  from  the  Services,  the  Joint 
Staff,  the  Defense  Finance  and  Accounting  Service  (for  pay  integration)  and 
OSD; 

•  the  purchase,  by  the  Services,  of  COE-compliant  platform-independent 
components  in  planned  equipment  modernization  efforts  not  only  to  support 
the  objective  system  but  to  meet  technical  guidelines  and  to  achieve  the 
benefits  of  high  performance;  and 

•  the  identification  of  investment  funds  to  design  and  develop  software  for  the 
objective  system  beginning  in  FY  97. 

The  report  and  its  recommendations  have  broad  support  from  the  OSD  staff  and 
the  Service  personnel  chiefs.  I  recommend  that  the  report  be  forwarded  to  the  Secretary 
of  Defense  with  a  strong  recommendation  for  implementation. 


Chairman 
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MEMORANDUM  FOR  CHAIRMAN,  DEFENSE  SCIENCE  BOARD 

SUBJECT:  Report  of  the  Defense  Science  Board  (DSB)  Task  Force  on  Military 
Personnel  Information  Management 


The  final  report  of  the  Task  Force  on  Militaiy  Personnel  Information  Management 
is  attached.  The  Task  Force  members  and  the  Advisors  have  unanimously  concluded  that 
the  present  situation,  in  which  the  Services  develop  and  maintain  multiple  Service-unique 
military  personnel  and  pay  systems,  has  led  to  significant  functional  shortcomings 
(particularly  in  the  Joint  arena)  and  excessive  costs  for  system  development  and 
maintenance  for  the  Department  of  Defense.  Moreover,  it  is  clear  to  the  members  that 
there  are  no  technical,  functional  or  programmatic  barriers  which  preclude  the  realization 
of  a  common  system  that  can  support  all  Services  and  all  components.  The  report, 
therefore,  recommends  a  single,  fully  integrated  personnel  and  pay  system  to  be  used  by 
all  components.  The  report  further  includes  supporting  recommendations  on  functional 
and  technical  criteria  for  the  objective  system;  a  transition  strategy;  and  a  management 
structure.  It  also  recommends  assignment  of  responsibilities  for  implementation. 

The  most  challenging  area  we  addressed  was  the  proposed  management  structure. 
The  report  reflects  the  clear  consensus  of  the  Task  Force  as  to  the  management  structure 
most  likely  to  ensure  successful  execution  of  the  program,  while  balancing  the  need  for 
clear  lines  of  authority  on  the  one  hand,  with  the  need  to  ensure  that  the  system  meets  the 
needs  of  the  individual  Services  on  the  other. 

It  has  been  my  privilege  and  pleasure  to  lead  this  Task  Force.  I  would  like  to 
e3q)ress  my  deep  appreciation  to  the  Task  Force  members  for  their  generous  participation 
and  invaluable  contributions.  Their  individual  and  collective  experience,  knowledge  and 
expertise  enabled  us  to  approach  the  issues  from  a  highly  professional  perspective.  The 
government  Advisors  and  OSD  and  Service  staffs  were  also  deeply  involved  in  our 
deliberations  and  provided  timely  and  useful  responses  to  our  questions.  Each  of  our 
meetings  was  characterized  by  vigorous  debate  and  an  in-depth  exploration  of  the  critical 
issues.  As  a  result,  I  believe  the  final  report  will  generally  enjoy  strong  support. 

I  recommend  that  you  forward  the  report  to  the  Under  Secretary  of  Defense 
(Acquisition  and  Technology). 


Salisbury, 


Chairman 


Preface 


This  is  the  Final  Report  of  the  Defense  Science  Board  Task  Force  on  Military  Personnel  Information 
Management.  This  Task  Force  was  convened  at  the  request  of  the  Under  Secretary  of  Defense  (Personnel 
and  Readiness)  and  the  Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence)  to  address  specific  issues  and  make  recommendations  regarding  the  direction  the 
Department  should  take  in  developing  and  maintaining  automated  systems  for  military  personnel  and  pay 
management,  across  the  four  Services,  and  including  both  active  and  reserve  components.  The  Task 
Force  met  monthly  beginning  in  February  1996,  and  concluded  its  work  in  August  1996. 

The  membership  of  the  Task  Force  reflects  a  broad  base  of  backgrounds  relevant  to  the  subject  matter. 
Included  are  former  Service  personnel  chiefs,  former  Service  automation  experts,  former  senior 
Department  of  Defense  personnel  and  policy  officials,  senior  academic  experts  on  information  systems, 
and  senior  information  systems  experts  from  industry. 

The  Task  Force  would  like  to  express  its  appreciation  to  the  Advisors  and  support  staff  from  the  military 
Services  and  Office  of  the  Secretary  of  Defense,  who  provided  superb  cooperation  and  support 
throughout  this  effort.  They  contributed  substantially  to  the  content  of  this  Final  Report.  It  is  our  hope 
that  the  Services  and  the  Department  of  Defense  will  materially  benefit  from  this  work,  and  that  the 
implementation  of  our  recommendations  will  result  not  only  in  significant  cost  savings,  but  in  improved 
functional  support  to  our  Soldiers,  Sailors,  Airmen  and  Marines,  who  deserve  the  very  best. 
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Final  Report 
of  the 

Defense  Science  Board  Task  Force 
on 

Military  Personnel  Information  Management 


I.  Introduction  and  Executive  Summary. 

% 

A.  Background. 

The  Defense  Science  Board  Task  Force  on  Military  Personnel  Information 
Management  was  established  to  advise  the  Secretary  of  Defense  on  the  best  automation 
strategy  to  support  the  military  personnel  and  pay  functions  for  all  active  and  reserve 
components  throughout  the  Department.  Convened  at  the  request  of  the  Under  Secretary 
of  Defense  (Personnel  and  Readiness)  and  the  Assistant  Secretary  of  Defense  (Command, 
Control,  Communications,  and  Intelligence),  the  Task  Force  was  asked  to  address  five 
items. 


1  -  Assess  the  Department's  military  personnel  information  management 
requirements  and  determine  the  most  desirable,  feasible,  and  cost-effective 
automation  solution:  for  instance,  one  integrated  active/reserve  military 
personnel/pay  system  or  multiple  interoperable  systems  sharing  a  common 
database. 

2  -  Assess  the  cost-effectiveness  of  adopting  and  reengineering  one  of  the 
Services’  existing  systems  as  the  standard  rather  than  initiating  new  development 
that  may  take  advantage  of  more  modem  technologies,  including  Commercial  Off 
The  Shelf  (COTS)  applications. 

3  -  Evaluate  the  strategy  being  pursued  by  the  military  personnel  community 
(OSD  and  the  Services)  which  includes  defining  detailed  requirements  for  data, 
interfaces,  and  functional  processes  for  joint  military  personnel  information 
management  and  designating  the  Navy  and  Air  Force,  respectively,  as  Executive 
Agents  for  the  design  and  development  of  field  and  database  level  applications 
which  would  support  core  requirements. 

4  -  Assess  the  strategy  for  dealing  with  Service  specific  systems  while  joint 
military  personnel  information  management  core  requirements  are  in 
development. 


5  -  Determine  how  to  ensure  that  current  military  personnel  operations  are  not 
interrupted  or  compromised  in  any  way  that  would  interfere  with  DoD’s  ability  to 
mobilize  or  provide  appropriate  support  to  military  personnel  and  veterans. 
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B.  Overview  of  Task  Force  Activities. 


The  Task  Force  convened  its  organizational  meeting  on  February  22, 1996.  Task 
Force  meetings  were  held  on  March  21/22,  April  29/30,  May  23,  June  26,  July  29,  and 
August  21.  Through  the  May  meeting,  the  Task  Force  focused  on  gathering  information 
and  data  relevant  to  the  issues  to  be  addressed.  Task  Force  members  received 
presentations  from  representatives  of  the  Office  of  the  Under  Secretary  (Personnel  and 
Readiness),  the  Office  of  the  Assistant  Secretary  (Command,  Control,  Communications, 
and  Intelligence),  the  Joint  Staff,  the  Defense  Information  Systems  Agency,  the  Defense 
Finance  and  Accounting  Service,  the  Service  Personnel  Chiefs,  the  United  Kingdom 
Personnel  Administration  Agency,  and  private  sector  organizations  which  provide  and 
use  automation  support  for  personnel  and  pay  functions. 

At  the  April  meeting,  issues  and  questions  raised  by  Task  Force  members  were 
categorized  into  functional,  technical,  and  programmatic  study  areas.  Task  Force 
members  were  assigned  to  teams  focusing  on  each  area,  with  the  understanding  that  all 
areas  were  open  to  all  members.  A  detailed  set  of  matrices  was  developed  by  OSD  and 
Service  staff  to  summarize  the  relevant  information  and  serve  as  the  basis  for  further 
review  and  discussion  at  the  May  and  subsequent  meetings.  This  set  of  matrices  is 
included  in  the  papers  at  Appendix  H. 

During  the  June  and  July  meetings.  Task  Force  members  focused  on 
recommendations  and  their  implementation.  The  August  meeting  was  devoted  to 
reviewing  the  final  Task  Force  findings  and  recommendations  (in  the  form  of  the  draft 
Final  Report)  with  the  Advisors  (who  represented  the  Services,  the  Joint  Staff,  and  OSD). 

All  meetings  were  conducted  in  a  completely  open  manner  with  full  participation 
by  the  Advisors,  and  the  opportunity  for  questions  and  comments  from  all  attendees, 
including  interested  vendor  organizations. 

C.  Summary  of  Conclusions  and  Recommendations. 

The  Task  Force  has  unanimously  concluded  that  the  present  situation,  in  which 
the  Services  develop  and  maintain  multiple  Service-unique  military  personnel  and  pay 
systems,  has  led  to  significant  functional  shortcomings  (particularly  in  the  joint  arena) 
and  excessive  costs  for  system  development  and  maintenance  for  the  Department  of 
Defense.  Moreover,  it  is  clear  to  the  members  that  there  are  no  technical,  functional  or 
programmatic  barriers  which  preclude  the  realization  of  a  common  system  that  can 
support  all  Services  and  all  components.  These  conclusions  were  also  supported  by  the 
Services. 

The  Task  Force  also  believes  that,  with  the  individual  Services  now  in  various 
phases  of  fielding  or  modernizing  their  systems,  and  with  the  Navy,  in  particular,  newly 
embarked  on  a  major  system  redevelopment  effort,  the  DoD  has  a  unique  window  of 
opportunity  available  to  it.  The  immediate  initiation  of  a  common  objective  system 
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program  can  yield  both  significant  savings  and  operational  efficiencies  for  the 
Department,  the  Services,  and  the  joint  commanders. 

The  Task  Force  has  further  concluded  that  the  best  acquisition  strategy  for  a 
common  objective  system  is  to  vigorously  pursue  a  COTS-based  solution.  Such  a 
solution,  which  is  strongly  supported  by  experience  in  commercial  industry  and  in  on¬ 
going  Air  Force  and  Navy  efforts,  will  pay  significant  dividends  in  both  cost  and 
schedule. 

With  the  collective  experience  and  expertise  of  the  Task  Force  members,  and  our 
clear  understanding  of  the  critical  success  factors  for  such  a  program,  we  have  chosen  to 
include  in  this  report  specific  recommendations  with  regard  to  both  the  development 
approach  (including,  for  instance,  the  use  of  COTS)  and  the  management  structure  most 
likely  to  succeed.  We  believe  that  our  report  would  not  be  complete  if  we  did  not  address 
these  vital  areas. 

A  brief  statement  of  the  major  recommendations  is  provided  below.  Additional 
information,  including  guidelines,  criteria,  supporting  recommendations  and  rationale,  is 
provided  in  Sections  III  and  IV  of  this  report. 

Common  Objective  System;  The  Task  Force  has  unanimously  concluded  that 
the  Department  should  move  to  a  single  all-Service  and  all-component,  fully 
integrated  personnel  and  pay  system,  with  common  core  software  built  on  a  COTS 
human  resources  software  application  base  (or  a  modified-COTS  system),  with  an 
Initial  Operating  Capability  of  2001  or  earlier.  The  system  should  incorporate 
standard  data  definitions,  meet  DoD  technical  Common  Operating  Environment 
(COE)  guidelines,  and  include  Service-specific  modules  as  required  for  maximum 
support. 

Development  Approach;  The  Task  Force  members  agree  that  the  key  to 
successful  implementation  is  the  definition  of  functional  requirements  in  a  joint 
environment.  The  Task  Force  recommends  an  acceleration  of  the  process  initiated 
by  the  Personnel  and  Readiness  Military  Personnel  Management  Joint  Working 
Group  to  define  functional  requirements  and  pass  them  to  Executive  Agents  for 
software  development.  The  process  of  defining  functional  requirements  must  be 
performed  by  the  personnel  community,  with  full  participation  from  the  Services, 
the  Joint  Staff,  the  Defense  Finance  and  Accounting  Service  (for  pay  integration) 
and  OSD.  Joint  requirements  should  incorporate,  to  the  maximum  extent 
possible,  best  commercial  practices  as  well  as  best  Service  practices,  with  the 
objectives  of  resolving  existing  functional  shortcomings,  minimizing  Service- 
unique  requirements,  and  maximizing  potential  COTS  utilization.  While  the 
functional  requirements  must  drive  the  solution,  care  must  be  taken  to  distinguish 
essential  requirements  from  processes  that  may  be  modified  without  adversely 
impacting  the  function.  The  Service  personnel  system  managers  must  look  for 
opportunities  to  follow  common  approaches  rather  than  pursuing  Service-specific 
options  where  common  solutions  are  clearly  workable. 
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Management  Structure;  The  Task  Force  recommends  that  the  current 
USD(P&R)  Information  Management  organization  be  restructured  and  designated 
as  the  Joint  Requirements  and  Integration  Office  (JR&IO),  as  part  of  a  field 
activity  reporting  to  the  USD(P&R).  The  JR&IO,  augmented  by  the  Military 
Personnel  Management  Joint  Working  Group  (JWG),  should  have  the  overall 
responsibility  for  defining  the  requirements  for,  and  directing  the  implementation 
of,  the  objective  all-Service  and  all-component  fully  integrated  personnel  and  pay 
system,  under  charter  from  the  Deputy  Secretary  of  Defense.  The  responsibilities 
of  this  office  should  include  overall  program  authority,  as  well  as  defining  and 
maintaining  a  set  of  common-core  and  Service-specific  requirements  for 
implementation  by  the  Executive  Agents.  The  JR&IO  should  coordinate  with  the 
Joint  Readiness  Oversight  Committee  (JROC)  to  ensure  that  the  objective  system 
continues  to  meet  the  needs  of  the  CINCs,  as  well  as  the  Services  and  OSD.  The 
office  should  be  responsible  for  programming  and  defending  the  funding  for  the 
objective  system  and  coordinating  the  efforts  of  the  Executive  Agents.  (Staff 
increases  will  be  necessary  to  fulfill  these  responsibilities.)  The  JR&IO  should  be 
headed  by  an  SES-level  civilian  Director. 

On  a  monthly  basis  initially,  and  not  less  than  quarterly,  JR&IO  should  review  the 
program  with  a  Steering  Committee  composed  of  the  Assistant  Deputy  Chiefs  of 
Staff  for  Personnel  (ADCSPERs)  from  the  Services,  and  senior  representatives 
from  OUSD(P&R),  OASD(Reserve  Affairs),  DFAS,  and  the  Joint  Staff. 
Chairmanship  of  the  Steering  Committee  should  rotate  annually  among  the  four 
Service  ADCSPERs,  with  initial  chairmanship  falling  to  the  Army.  This  Steering 
Committee  should  set  overall  priorities,  and  provide  advice  and  recommendations 
to  the  USD(P&R)  and  the  JR&IO  regarding  program  execution  throughout  the  life 
cycle  process  of  requirements  definition,  software  acquisition/development, 
hardware  acquisition,  fielding  and  follow-on  maintenance  functions.  The  Steering 
Committee  should  issue  an  annual  written  report  to  the  Deputy  Secretary  of 
Defense  providing  the  committee’s  assessment  of  the  progress  of  the  program. 

Transition  Strategy:  The  Task  Force  recommends  that  detailed  Service-specific 
implementation  plans  for  the  objective  system  be  completed  by  the  end  of  FY  97. 
The  implementation  plans  should  include  dates  for  phasing  out  existing  systems, 
commensurate  with  the  operational  capability  of  the  objective  system.  The  Task 
Force  recommends  the  following  Service-by-Service  transition  strategy: 

•  The  Army  should  field  the  Standard  Installation  Division  Personnel 
System-3  (SIDPERS-3)  as  planned.  The  hardware  deployed  to  support 
SIDPERS-3  should  be  platform-independent  and  should  also 
accommodate  the  software  of  the  objective  system.  The  Army  should 
maximize  the  use  of  existing  SIDPERS-3  software  in  the  Reserve 
Component  Automation  System  (RCAS)  personnel  module,  while 
deferring  new  development  of  personnel  software  for  RCAS  to  permit 
incorporation  of  the  objective  system. 
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•  The  Navy  should  refocus  its  primary  effort  on  developing  the  objective 
system.  Without  materially  delaying  its  accelerated  development  and 
deployment  schedule  for  critically  needed  NSIPS  capabilities,  current 
NSIPS  efforts  should  be  broadened  to  encompass  the  objective  system 
requirements  as  they  are  developed  by  the  JR&IO.  Wherever  possible, 
pressing  NSff  S  requirements  should  be  satisfied  through  early  incremental 
fielding  of  objective  system  modules.  The  Navy  should  continue  its  role  as 
Executive  Agent  for  the  field  level  component  of  the  objective  system. 

•  The  Air  Force  should  refocus  on  the  objective  system  instead  of 
proceeding  with  plans  to  modernize  its  Air  Force-unique  field  level 
system.  The  Air  Force  should  continue  its  role  as  the  Executive  Agent  for 
the  corporate  tier  and  system  architecture  of  the  objective  system. 

•  The  Marine  Corps  should  refocus  its  functional  and  technical  enhancement 
plans  to  the  objective  system.  The  Marine  Corps  representatives  in  the 
JR&IO/JWG  should  play  the  lead  role  in  defining  the  functional 
requirements  for  effective  integration  of  personnel  and  pay. 

Infrastructure;  The  Services  are  in  different  positions  with  respect  to 
modernization  of  their  infrastructure.  The  Services  should  retain  responsibility 
for  acquiring,  deploying,  and  maintaining  the  infrastructure  and  hardware 
platforms  required  to  support  the  objective  system.  Purchase  of  COE-compliant 
platform-independent  components  in  planned  equipment  modernization  efforts  is 
required,  not  only  to  support  the  objective  system  but  to  meet  technical  guidelines 
and  to  achieve  the  benefits  of  high  performance. 

Funding:  Investment  funds  will  be  required  to  define  functional  requirements 
and  design,  develop,  and  test  software  for  the  objective  system.  The  Task  Force 
recommends  that  USD(Comptroller)  immediately  take  steps  to  address  the 
funding  shortfalls  for  FY  97  and  FY  98.  (Exhibit  1  of  Appendix  A  provides  an 
estimate  of  funds  required  for  the  development  of  joint/common  requirements  and 
for  the  development  of  OSD  and  Joint  Staff  requirements  and  the  associated 
software  development.)  Additional  funding  must  also  be  identified  from  the 
Services  to  support  definition  of  their  unique  functional  requirements.  Investment 
funds  should  be  allocated  to  the  Joint  Requirements  and  Integration  Office. 

D.  Report  Contents. 

Section  I  of  this  Final  Report  provides  an  Introduction  and  Executive  Summaiy. 
Section  n  provides  a  detailed  Statement  of  the  Problem,  addressing  Functional 
Shortcomings,  Excessive  Costs,  and  Infrastructure  Inadequacies  in  some  detail.  Section 
HI  identifies  Significant  Issues  and  Critical  Success  Factors  in  Functional,  Technical  and 
Programmatic  areas.  Section  HI  also  includes  a  number  of  recommended  criteria, 
guidelines,  and  supporting  recommendations  and  rationale  that  follow  from  the 
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discussion  of  the  issues.  Major  recommendations  are  detailed  in  Section  IV,  and  a 
recommended  Assignment  of  Responsibilities  for  implementation  actions  is  provided  in 
Section  V.  (Note:  While  all  the  Appendices  are  on  the  Internet,  copies  of  Appendices  A 
through  D  are  included  here  for  the  convenience  of  the  reader.) 

There  are  eight  appendices  to  this  report.  They  can  be  accessed  on  the  web  with 
the  homepage  address:  http://www.mpm.osd.mil.  Exhibits  referenced  in  the  main  body 
of  the  report  are  included  at  Appendix  A.  The  Task  Force  membership  is  at  Appendix  B. 
The  Terms  of  Reference  which  guided  the  Task  Force  deliberations  are  at  Appendix  C. 
Mapping  of  the  recommendations  to  the  questions  in  the  Terms  of  Reference  is  at 
Appendix  D.  The  agenda  for  the  meetings  are  at  Appendix  E  and  the  meeting  summaries 
at  Appendix  F.  Appendix  G  contains  correspondence  received  by  and/or  generated  by 
Task  Force  participants  relevant  to  the  deliberations.  Information  papers  requested  by 
and  prepared  for  the  Task  Force  are  at  Appendix  H. 
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n.  Statement  of  the  Problem. 


The  Task  Force  members  identified  three  principal  problem  areas  in  military 
personnel  management  automation  support:  1)  functional  shortcomings  in  the  existing 
capabilities;  2)  excessive  costs  in  developing  and  maintaining  largely  redundant 
capabilities;  and  3)  the  inadequacy  of  the  current  infrastmcture  relative  to  required 
operational  capabilities.  The  Task  Force  agreed  that  any  recoimnendations  made  must  be 
designed  to  have  a  positive  impact  on  each  of  these  problems.  Additionally,  the  Task 
Force  agreed  that  a  guiding  principle  should  be  to  “do  no  harm.”  This  means  simply  that 
the  Task  Force  recommendations,  when  implemented,  should  not  cause  any  Service  to 
end  up  with  functional  capabilities  that  are  inferior  to,  or  more  costly  than,  its  current 
capabilities.  The  three  problem  areas  (which  are  reflected  in  the  individual  Services  to 
varying  degrees)  are  summarized  in  the  discussion  that  follows: 

A.  Functional  Shortcomings. 

During  the  Persian  Gulf  War,  many  problems  highlighted  the  shortcomings  of  the 
existing  military  personnel  systems  in  providing  timely  and  accurate  data  on  deployment, 
mobilization,  and  theater  assets.  In-theater,  it  was  difficult  for  joint  commanders  to  get 
information  on  the  capabilities  and  locations  of  military  personnel  essential  to 
assessments  of  operational  capabilities.  For  the  Services  and  OSD  managers  and 
analysts,  it  was  difficult  to  confirm  even  the  broadest  characteristics  of  the  individuals 
deployed  or  the  mobilized  force  (active  and  reserve  components).  For  the  Service 
member,  pay  and  benefits  were  often  delayed  or  inaccurate  and  personnel  records 
incomplete  to  the  extent  that  appropriate  credit  was  not  always  given  for  service. 

Much  of  the  discussion  throughout  the  Task  Force  meetings  focused  on  these  and 
other  functional  shortcomings  of  existing  capabilities.  The  degree  and  nature  of  the 
shortcomings,  which  differ  across  the  Services,  impact  on:  the  operational  managers  in 
the  joint  arena  (both  in  peacetime  and  in  war);  personnel  managers  in  the  Services;  OSD 
managers  and  analysts;  and  the  individual  Service  members. 

There  is  a  clear  adverse  impact  of  multiple  Service-unique  systems  in  the  joint 
arena.  In  order  to  conduct  operations  and  manage  a  fighting  force,  joint  commanders 
require  information  that  is  timely,  accurate,  and  consistent  across  the  Services.  Today, 
joint  commanders  are  dependent  on  Service-unique  personnel  systems  that  do  not  provide 
consistent  and  comparable  information  and  that  vary  significantly  in  accuracy  and 
timeliness. 

Existing  systems  in  each  of  the  Services  provide  most  of  the  capabilities  required 
to  support  the  Service  personnel  managers.  In  both  the  Army  and  the  Navy,  however, 
significant  problems  arose  in  tracking  personnel  as  they  changed  from  reserve  to  active 
status  and  back  and  as  they  deployed  to  support  contingencies  on  an  individual  basis. 

Both  Services  have  initiated  efforts  to  resolve  these  problems. 
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-  The  Navy  is  redesigning  and  consolidating  its  systems  at  both  the  headquarters 
and  field  levels  to  ensure  a  fully  integrated  personnel  support  capability. 

Although  this  effort  has  only  recently  been  initiated,  both  the  functional  and 
system  managers  are  working  closely  with  an  OSD-led  joint  effort  to  define 
common  requirements  and  with  the  Air  Force  to  benefit  from  the  Air  Force 
corporate  tier  modernization. 

-  The  Army  is  almost  ready  to  field  a  new  system  that  will  provide  greatly 
enhanced  support  to  personnel  managers  for  their  active  duty  personnel. 
Unfortunately,  many  of  the  fixes  required  to  support  tracking  personnel  in  status 
changes  and  in  deployment  are  dependent  on  two  other  modernization  efforts  that 
are  not  as  far  along:  modernization  of  their  headquarters  database  and 
modernization  of  their  reserve  component  support  system. 

The  major  impacts  on  OSD  managers  and  analysts  mirror  those  on  managers  in 
the  joint  arena  and  Service  personnel  managers.  Inconsistent  information  that  varies 
significantly  in  accuracy  and  timeliness  across  the  Services  makes  it  difficult  to  develop 
guidance,  analyze  requirements,  and  respond  to  inquiries  from  Congress  and  others. 
While  internal  personnel  problems  present  difficulties  for  the  OSD  personnel  community, 
the  financial  community  is  also  hindered  by  the  need  to  work  with  personnel  systems  that 
provide  varying  degrees  of  accuracy  and  timeliness  on  information  required  to  calculate 
and  process  pay  for  Service  members. 

The  consequences  for  the  individual  Service  members  are  always  burdensome  and 
sometimes  painful.  They  include:  the  need  to  spend  months  in  efforts  to  get  service 
records  straightened  out  (to  ensure,  for  instance,  proper  credit  for  retirement,  or  proper 
documentation  of  deployment);  difficulties  in  accessing  benefits  for  members  and  their 
families;  and  delays  in  pay  and  allotments.  All  of  these  damage  the  morale  and  welfare 
of  the  Service  members  and  their  families. 

While  the  proposed  objective  system  may  generate  savings  associated  within  the 
functional  processes,  its  primaiy  benefits  should  come  from  enhanced  performance  and 
support  to  the  Service  and  joint  commanders,  OSD  managers,  and  individual  Service 
members. 

B.  Excessive  Costs. 

Considerable  resources  are  now  being  expended  on  maintaining  multiple  separate 
Service/component  systems,  and  significantly  greater  resource  expenditures  are  required 
to  provide  for  their  modernization.  Current  cooperative  efforts  among  the  Services, 
particularly  between  the  Air  Force  and  the  Navy,  would  indicate  that  there  is  some 
potential  for  cost  reduction  through  voluntary  initiatives;  the  Task  Force  view,  however, 
is  that  such  efforts  by  themselves  are  very  unlikely  to  realize  the  full  benefits  that  could 
result  from  a  common  system  across  four  Services.  At  the  same  time,  existing 
cooperation  provides  strong  evidence  that  truly  joint  efforts  are  workable  and  can  yield 
significant  results. 
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There  are  three  areas  where  costs  should  be  reduced  through  moving  to  a  single 
system:  1)  future  development;  2)  maintenance;  and  3)  functional  efficiencies  resulting 
from  the  adoption  of  best  practices.  Each  of  these  areas  is  briefly  addressed  below. 

1.  Future  Development: 

Substantial  savings  should  result  from  the  development  and  maintenance  of  a 
common  system,  although  a  front-end  investment  is  required  due  to  the  initial  joint 
requirements  development  effort.  In  total,  however,  this  investment  should  be 
significantly  less  than  the  resources  the  Services  could  be  expected  to  expend  in  pursuing 
their  individual  modernization  efforts. 

Although  all  future  development  costs  are  not  reflected  in  the  current  Future  Year 
Defense  Plan  (because  each  of  the  Services  is  currently  at  a  different  life-cycle  stage),  the 
future  implications  of  the  current  practices  are  clear.  Each  Service,  in  turn,  will  reach  the 
point  where  the  next  modernization  effort  must  be  initiated.  The  Army,  for  instance,  is 
near  completion  with  the  software  development  phase  of  SIDPERS-3,  but  can  be 
expected  to  be  looking  towards  its  replacement  in  a  few  years.  The  Navy  recently 
completed  development  of  the  Source  Data  System  for  active  duty  personnel  and  is  now 
pursuing  the  next  modernization  effort  with  NSIPS. 

The  historical  pattern  of  modernization  resulting  from  multiple  systems  clearly 
extrapolates  to  multiple  future  expenditure  streams  on  modernization  efforts.  The 
development  of  a  single  system  will  require  an  up-front  investment  that  will  slightly 
exceed  the  modernization  costs  of  a  single  Service-unique  system,  but  will  clearly  be  less 
than  the  aggregate  of  new  starts  that  stretch  out  in  future  years.  When  future 
modernization  is  required,  all  modernization  would  be  from  a  common  base. 

Technical  experts  pointed  out  that,  even  if  functional  requirements  change  during 
the  development  process,  there  are  great  technical  and  cost  advantages  associated  with 
creating  this  common  baseline  for  future  modifications. 

2.  Maintenance: 

It  is  difficult  to  differentiate  fully  between  the  savings  expected  from  the 
elimination  of  multiple  future  starts  and  the  savings  expected  from  the  need  to  maintain 
only  one  system.  The  United  Kingdom  Personnel  Administration  Agency  presented 
expectations  of  cost  savings  of  up  to  thirty  per  cent  on  the  maintenance  of  a  harmonized 
personnel  and  pay  delivery  system  for  their  military.  Similarly,  the  experiences  of  the 
Marine  Corps  and  the  Air  Force  in  consolidating  and  integrating  their  systems  suggest 
significant  savings  and  the  Functional  Economic  Analysis  for  the  Navy  Standard 
Integrated  Personnel  System  projected  savings  from  their  internal  consolidation  and 
integration.  During  the  life-cycle  of  a  system,  new  requirements  are  frequently  identified 
that  result  from  Congressional  actions,  policy  decisions,  and  opportunities  for  improved 
performance.  With  multiple  systems,  updates  and  revisions  must  be  made  to  each 


9 


system,  resulting  in  duplication  of  effort  and  unevenness  of  results.  With  a  single  system, 
there  will  be  a  need  for  a  single  set  of  updates  and  revisions,  with  a  coordinated 
interpretation  of  the  requirement,  and  a  more  uniform  functional  impact. 

3.  Best  Practices: 

The  process  for  defining  requirements  for  the  objective  system  will  provide  an 
opportunity  for  the  adoption  of  best  practices  across  the  Department,  and  in  many  cases 
from  the  private  sector  as  well,  as  COTS  packages  and  underlying  practices  are  reviewed. 
The  process  also  provides  an  opportunity  for  identifying  inconsistencies  in  management 
due  to  Service-unique  interpretations  and  implementations  of  policies.  Although  the  full 
functional  impact  cannot  yet  be  predicted,  experience  within  the  military  personnel 
business  process  reengineering  program  has  demonstrated  that  there  are  many 
opportunities  for  improving  functional  performance  and  efficiencies,  and  eliminating  any 
inequities  that  may  exist.  In  some  cases,  improved  performance  may  be  the  primary  goal, 
whether  or  not  there  are  savings  (for  instance  in  providing  operational  support  to  the 
CINCs  or  in  ensuring  accuracy  of  personnel  records).  There  will  also  be  administrative 
areas  where  current  practices  can  be  refined  in  ways  that  will  lead  to  efficiencies. 

C.  Infrastructure  Inadequacies. 

A  final  problem  area,  related  both  to  the  functional  shortcomings  and  the  costs,  is 
the  inability  of  the  current  infrastructure  (computer  system  platforms)  to  support  the  full 
operational  capabilities  required  for  each  of  the  Services  under  current  plans.  Much  of 
the  existing  infrastructure  is  actually  obsolete.  Modernization  of  equipment  must  take 
place,  whether  joint  or  Service-unique,  to  achieve  the  benefits  offered  by  high- 
performance,  open  system  hardware  platforms.  The  Army  and  Navy  are  currently 
planning  such  acquisitions.  The  same  modem  platform-independent  infrastructures  that 
are  required  under  current  plans  can  also  be  effectively  used  to  implement  the  objective 
system. 
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in.  Signiflcant  Issues  and  Critical  Success  Factors. 

Task  Force  members  identified  several  potential  issues  that  could  impact  the 
ability  of  the  Department  to  proceed  in  developing  effective  automation  support  for 
military  personnel  management.  These  potential  issues  fall  into  three  main  categories: 
functional  issues;  technical  issues;  and  programmatic  (scheduling,  managerial  and 
funding)  issues.  Each  category  is  addressed  below,  along  with  a  discussion  of  important 
considerations  and  critical  success  factors. 

A.  Functional  Issues. 

1.  Joint  Requirements: 

In  order  to  successfully  implement  consistent  and  effective  automation  support 
through  a  common  system,  there  must  be  a  common  statement  of  functional 
requirements.  This  statement  of  requirements  must  clearly  definitize  both  the  common 
processes  that  are  achievable  and  necessary,  as  well  as  the  truly  unique  processes  that  are 
required  for  the  individual  Services  to  provide  the  essential  complement  of  military 
personnel  and  pay  support  services.  This  statement  should  include:  the  degree  to  which 
common  business  practices  are  achievable/desirable;  a  full  definition  of  the  functional 
requirements  for  personnel  and  pay  integration;  and  a  description  of  an  overall  functional 
architecture.  Functional  requirements  must  also  address  security  issues,  including  privacy 
and  integrity,  in  both  operations  and  communications.  Short-term  needs  (e.g.,  to  provide 
immediate  relief  to  the  field  in  the  form  of  basic  automation  support)  must  be  reconciled 
with  long-term  objectives. 

As  a  tool  to  assist  in  the  definitization  and  analysis  of  requirements,  the  Task 
Force  noted  that  a  number  of  domain  analysis  approaches  have  evolved  over  the  past  few 
years,  particularly  in  support  of  software  reuse  efforts,  that  could  be  used  productively  in 
examining  military  personnel  management.  These  analyses  will  provide  insight  into  the 
personnel  system  structure  that  will  support  commonalities. 

The  Task  Force  received  functional  presentations  from  the  Joint  Staff,  the 
Services,  and  OSD  staff  and  studied  the  functional  matrices  developed  in  response  to  our 
questions.  As  noted  earlier  in  the  discussion  of  problems  (Section  H),  one  of  the  major 
shortcomings  of  the  current  systems  is  their  inability  to  fully  satisfy  the  requirements  of 
the  joint  commanders  and  the  Joint  Staff,  and,  to  a  lesser  extent,  OSD  managers  and 
analysts.  The  Joint  Personnel  Asset  Visibility  system  (JPAV),  for  instance,  requires  data 
from  the  Service  systems  and  will  clearly  benefit  from  a  common  objective  system.  As  a 
matter  of  priority,  special  attention  needs  to  be  paid  to  formally  definitizing  all  of  these 
requirements  so  the  Services  can  respond  better  to  them.  This  definitization  effort  should 
be  accompanied  by  an  equal  effort  and  emphasis  on  minimizing  these  Joint  and  OSD 
requirements  to  the  smallest  possible  set  consistent  with  true  needs. 

The  Task  Force  was  impressed  with  the  results  to  date,  albeit  in  very  limited 
functional  areas,  in  achieving  commonality  in  requirements  between  the  Services,  and  in 
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the  further  ability  to  find  acceptable  commercial  best-practice  solutions  as  embodied  in 
COTS  human  resources  software  (see  below).  The  Task  Force  is  thus  confident  that  a 
common  system  is  achievable  and  that  a  joint  environment  for  defining  a  common 
integrated  personnel  and  pay  system  will  provide  an  opportunity  for  the  Services, 
individually  and  collectively,  to  further  capitalize  on  the  best  practices  available 
(commercial  or  Service). 

2.  Joint  Requirements  Definition: 

The  experiences  of  the  Personnel  and  Readiness  Military  Personnel  Management 
Joint  Working  Group  were  reviewed  and  found  to  be  both  effective  and  valid  as  a  basis 
for  defining  requirements  and  developing  software  for  the  objective  system.  The 
approach  includes  a  full  analysis  of  the  military  personnel  management  function,  as 
defined  by  the  existing  process  model.  To  meet  an  IOC  date  of  2001  or  earlier,  it  will  be 
necessary  to  accelerate  the  current  processes  for  defining  requirements  and  developing 
software.  OUSD(P&R)  provided  an  estimate  of  the  resources  required  to  expedite 
completion  of  these  two  tasks  (Exhibit  1,  Appendix  A). 

One  of  the  assumptions  made  in  developing  both  the  timeline  and  resource 
estimate  was  that,  based  on  the  experience  of  the  Joint  Working  Group,  three  months  are 
required  to  fully  develop  the  requirements  for  each  of  the  135  personnel  management 
functional  nodes.  Through  parallel  efforts,  the  total  time  required  for  requirements 
development  is  estimated  at  30  months.  The  Task  Force  believes  that,  with  proper 
support  and  a  sense  of  urgency,  the  time  required  per  node  can  (and  should  be)  reduced  to 
two  months  or  less. 

Two  alternatives  were  presented  for  staffing  the  process  for  defining  functional 
requirements.  These  included  a  “Team”  approach  (with  multiple  teams  of  functional 
experts  assigned  full-time  to  the  requirements  development  task  for  the  duration  of  the 
effort),  and  a  “Workshop”  approach  (with  a  small  standing  full-time  team,  augmented  by 
Service  subject  matter  experts  for  intensive  short-term  work  on  individual  requirements). 
Both  alternatives  accelerate  the  current  process  from  one  module  (or  node)  every  three 
months  to  twelve  modules  every  three  months.  Both  alternatives  assume  significant 
contractor  support,  which  must  be  supported  through  funding  lines,  and  both  alternatives 
assume  continued  support  from  the  OUSD(P&R)  Information  Management  office  or 
some  comparable  organization. 

The  Task  Force  members  and  Advisors  considered  the  pros  and  cons  of  each 
approach  and  concluded  that  the  workshop  approach  is  best.  Although  there  may  be 
some  economies  from  continuity  in  the  team  approach,  the  workshop  approach  offers  the 
opportunity  to  tap  into  the  best-available  functional  area  expertise  throughout  the  Service 
personnel  communities.  It  further  offers  a  higher  probability  of  buy-in  to  the  results,  since 
there  would  be  greater  participation  by  those  actually  responsible  for  providing  personnel 
support.  (Per  Exhibit  1,  this  approach  is  estimated  to  require  an  office  of  about  60  people 
during  an  initial  two  and  a  half  year  period  devoted  to  definition  of  requirements.  After 
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requirements  are  completely  defined,  the  staffing  would  be  reduced  to  about  25  for 
continuing  maintenance  and  integration  functions.) 


3.  Personnel  and  Pay  Integration: 

Considerable  discussion  was  devoted  to  the  subject  of  personnel  and  pay 
integration.  Since  most  compensation  flows  directly  from  data  and  events  entered  in 
personnel  systems,  it  was  clear  to  Task  Force  members  that  personnel  and  pay  should  be 
managed  as  a  single  system.  The  Task  Force  thus  accepts  and  fully  supports  the 
importance  of  such  integration,  particularly  as  it  impacts  on  the  individual  Service 
member’s  ability  to  get  one-stop  support  with  data  entered  only  once  for  both  purposes, 
and  also  with  regard  to  eliminating  the  need  for  manual  data  reconciliation. 

The  Task  Force  recognizes  that  DFAS  is  the  principal  DoD  executive  agency  for 
finance  and  accounting  requirements,  operations,  systems,  and  functions.  As  such,  DFAS 
must  fully  participate  in  the  design,  development,  implementation  and  operations  of  the 
pay  functionality  of  the  objective  system.  As  the  DoD  paymaster,  DFAS  should 
participate  as  a  full  partner  in  the  development  decisions  of  the  objective  system  and  the 
gap  analysis  to  ensure  that  an  appropriate  assessment  is  made  of  commercial  and  Service 
practices  with  the  goal  of  maximizing  the  degree  of  commonality  and  the  potential  use  of 
COTS. 


The  Task  Force  members  and  the  Advisors  considered  a  number  of  ways  in  which 
personnel  and  pay  integration  could  be  defined.  The  Task  Force  concluded  that  a  “fully 
integrated  personnel  and  pay  system”  should  meet  the  following  criteria:  one-time  entry 
of  data  that  automatically  triggers  all  personnel  and  pay  transactions;  one-stop  shopping 
for  personnel  and  pay  transactions  for  the  Service  members  and  managers;  one  set  of  fully 
automated  edits  per  function;  and  processing  that  does  not  require  manual  reconciliation 
or  intermediate  data  entry.  From  a  logical  standpoint,  each  Service  would  have  a  single 
personnel  and  pay  system  with  a  single  database.  From  a  technical  or  physical 
standpoint,  modem  technology  and  modular  system  development  approaches  may  result 
in  a  system  with  separate  (and  possibly  distributed)  modules  and/or  automatically 
replicated/  synchronized  database  components.  But  the  user  must  see  a  single,  fully 
integrated  system,  providing  combined  personnel  and  pay  functionality  as  described 
above. 


It  is  important  to  note  that  integration  of  pay  and  personnel  systems  has  significant 
implications  for  adoption  of  COTS.  COTS  evaluation  and  selection  processes  need  to 
include  appropriate  criteria  to  ensure  that  a  final  solution  meets  this  critical  integration 
requirement. 
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4.  Objective  System  Functional  Criteria: 


The  Task  Force  believes  that  as  a  minimum,  a  common,  integrated  personnel  and 
pay  system  should  meet  the  following  criteria: 

j 

•  facilitate  support  for  the  joint  commands  by  ensuring  accurate  and 

timely  availability  of  consistent  data  across  the  Services;  ! 

•  promote  common  definitions  and  understandings; 

•  achieve  best  practices  and  streamline  processes  across  the  Services; 

•  provide  for  one-stop  shopping  for  personnel  and  pay  transactions  for  | 

Service  members  and  managers,  to  include  one-time  entry  of  data  that  ' 

automatically  triggers  all  appropriate  actions; 

•  provide  equal  support,  whether  in  garrison  or  deployed; 

•  provide  for  fully  automated  edits  and  processing  that  require  no 
manual  reconciliation  or  intermediate  data  entry; 

•  provide  accuracy,  responsiveness,  timeliness  and  consistency  of  data 
and  information  availability  and  accessibility; 

•  improve  security  and  accountability;  and 

•  support  individual  Service  requirements  for  interoperability  with  other 
Service  systems. 

5.  COTS  Functional  Considerations:  j 

I 

The  Task  Force  spent  extensive  time  considering  the  potential  benefits  of  a 
COTS-based  solution.  Briefings  from  vendors  who  supply  COTS  Human  Resource 
software  systems  to  government  and  industry  were  received;  case  studies  in  the  literature 
were  reviewed;  and  the  on-going  efforts  by  the  Air  Force  and  Navy  in  analyzing  COTS  in 
detail  were  also  reviewed. 

There  is  compelling  evidence  that  COTS  systems  can  satisfy  a  tremendous  range 
of  Human  Resource  (HR)  and  personnel  requirements  in  diverse  organizations.  Major 
corporations,  having  multiple  unique  business  units  in  different  countries  with  different  ^ 

laws  and  cultures,  have  still  managed  to  adopt  COTS  to  satisfy  their  requirements.  Most 
COTS  solutions,  however,  are  not  totally  “one-size-fits-all”  in  nature;  rather,  they  have 
the  ability  to  extend,  modify,  parameterize  with  tables,  or  otherwise  accommodate  unique 
requirements.  1 
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Clearly  the  four  Services  are  separate  and  distinct  organizations  with  many 
fundamental  differences;  these  differences,  however,  are  far  fewer  in  number  than  their 
commonalities.  Further,  these  differences  are  not  sufficient  to  justify  unique  Service 
programs,  and  in  no  way  preclude  the  development  of  a  common  objective  system.  The 
on-going  “Gap  Analysis”  (referring  to  the  “gap”  between  requirements  and  COTS 
capabilities)  being  conducted  by  the  Air  Force  has  recently  resulted  in  an  estimate  that  at 
least  60  per  cent  of  their  functional  requirements  can  be  fulfilled  by  an  available 
commercial  software  package  (Oracle  Human  Resources).  Pending  final  results  of  such 
an  analysis,  these  factors  confirm  that  pursuing  a  common  system  for  all  services,  based 
on  a  COTS  solution,  is  a  sound  direction.  Equally  important,  a  good  COTS  solution  can 
provide  the  capabilities  for  tailoring  Service-unique  requirements  where  they  can  be 
justified. 

Considerations  regarding  the  use  of  COTS  extend  beyond  functionality. 
Additional  discussion  is  included  below  in  the  Technical  Issues  area,  particularly  with 
regard  to  the  selection  process.  In  addition,  the  above  discussion  on  personnel  and  pay 
integration  indicates  implications  that  need  to  be  considered  relative  to  COTS  selection. 

B.  Technical  Issues. 

The  Task  Force  received  technical  briefings  from  each  of  the  Services  on  their 
current  and  planned  personnel  systems,  and  on  DoD  technical  standards  from  the  Defense 
Information  Systems  Agency  (DISA).  We  studied  the  detailed  technical  matrices  that 
were  prepared  in  response  to  our  questions.  The  Task  Force  agreed  that  there  are  no 
technical  barriers  to  development  of  a  common  system  that  includes  Service-unique 
modules  required  for  mission  support. 

1.  COTS  Selection: 

As  indicated  in  the  COTS  Functional  Issues  discussion  above,  the  Task  Force 
heard  from  representatives  of  private  industry  on  their  experiences  with  automating 
personnel  and  pay  functions  and  from  vendors  of  COTS  personnel  and  pay  applications 
and  software  development  tools.  In  addition,  we  examined  closely  the  on-going  efforts 
led  by  the  Air  Force,  and  followed  by  the  Navy,  in  reviewing  COTS  systems  for  use  in 
their  individual  personnel  and  pay  system  modernization  programs.  The  Task  Force 
members  determined  that  the  direction  of  the  Air  Force  and  Navy,  towards  a  modified 
COTS  solution,  is  not  only  technically  feasible,  but  it  potentially  presents  the  best  means 
of  implementing  the  objective  system. 

Both  functional  and  technical  considerations  must  be  applied  in  the  process  of 
selecting  COTS.  Notwithstanding  the  work  of  the  Air  Force  and  Navy,  which  led  to  the 
use  of  COTS  in  their  current  prototyping  efforts,  a  more  comprehensive  review  and 
analysis  should  take  place  before  finalizing  a  COTS  base  for  the  objective  system.  The 
adoption  of  a  comprehensive  review  and  selection  methodology  and  its  proper  execution 
must  be  regarded  as  among  the  critical  success  factors  for  this  program. 
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The  Chief  of  Research  and  Development  from  the  Canadian  Department  of 
Defense  has  undertaken  research  projects  to  understand  the  problems  associated  with 
COTS-based  software  development  from  the  perspective  of  an  organization  that  is  trying 
to  use  COTS  components  to  build  systems.  They  have  provided,  via  the  INTERNET,  a 
pertinent  research  paper  from  the  National  Research  Council  of  Canada  Institute  of 
Information  Technology  Software  Engineering  Group:  “COTS  Software  Integration  State 
of  the  Art”  January  1996  (Exhibit  2  in  Appendix  A).  This  paper  provides  the 
characteristics  of  off-the-shelf  based  system  development,  current  practices  within  both 
Canadian  Military  and  NASA,  experiments  with  open  scripted  architecture,  and  issues 
with  COTS  software  integration.  This  paper  also  provides  a  particularly  valuable 
guideline  for  accomplishing  a  comprehensive  review  and  selection  of  COTS.  A  relevant 
case  study  on  the  evaluation  and  selection  of  a  COTS  HR  system  appeared  in  Datamation 
Magazine,  June  15,  1995  (Exhibit  3  in  Appendix  A).  The  article  includes  a  feature 
comparison  chart  and  a  summary  “report  card”  that  can  be  used  as  one  model  for  the  kind 
of  review  that  should  be  done.  Another  evaluation  model,  based  on  “Feature  Comparison 
Charts,"  is  included  in  Exhibit  4  in  Appendix  A.  In  addition,  four  vendors  responded  to 
the  Task  Force’s  invitation  to  submit  recommendations,  offering  their  suggestions  for 
factors  to  be  considered  in  the  COTS  selection  process  (Exhibits  5, 6, 7,  and  8  in 
Appendix  A). 

Because  of  its  importance  to  the  success  of  this  program,  and  the  potential 
implications  for  future  competitive  procurements,  the  Task  Force  has  identified  COTS 
selection  as  a  critical  success  factor,  and  recommends  that  a  COTS  Analysis  and 
Evaluation  Plan  be  developed  and  approved  as  an  early  step  in  the  program  to  arrive  at 
the  objective  system.  In  addition  to  the  recommended  objective  system  functional  criteria 
and  COTS  functional  considerations  described  above,  some  of  the  factors  to  be 
considered  in  such  a  plan  include: 

•  functionality  “out-of-the-box”  vs  customization; 

•  scaleability  and  extensibility  of  the  COTS  product; 

•  integration  of  personnel  and  pay  functions; 

•  integration  with  multiple  database  options  (Open  Database); 

•  interface  with  open,  non-proprietary,  portable  development  tools; 

•  vendor  experience  and  stability;  and 

•  (possible)  Benchmarking  results. 

Finally,  most  of  the  discussion  of  COTS  has  focused  on  the  functional 
applications  and  the  analyses  to  determine  fit.  Although  these  are  important 
considerations,  especially  in  determining  whether  or  not  to  use  COTS  for  a  particular 
application  within  the  objective  system,  a  COTS  beise  provides  a  comprehensive  support 
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structure  that  is  independent  of  the  specific  applications.  This  structure  includes  such 
elements  as:  data  structure;  replication;  query  capabilities;  training;  web  access;  and 
software  services  upon  which  tailored  applications  may  be  built.  As  noted  in  several 
studies,  the  development  of  software  for  specific  applications  may  represent  as  little  as  20 
per  cent  of  the  total  software  development  required  to  field  a  system.  The  functional  gap 
analyses,  then,  are  focused  on  a  small  percentage  of  the  total  software  package.  The 
recommended  review  and  analysis  of  the  potential  for  a  COTS  solution  must  take  into 
account  the  benefits  from  the  overall  structure.  The  requirements  for  this  structure  should 
include:  compatibility  with  technical  and  functional  requirements  (stated  elsewhere)  and 
the  flexibility  to  make  decisions,  on  a  module  by  module  basis,  whether  to  use  the 
available  COTS  application  or  to  use  compatible  CASE  tools  to  generate  a  more  tailored 
application.  For  users,  the  underlying  use  of  different  approaches  to  different  functional 
applications  should  be  transparent,  with  both  COTS  and  non-COTS  modules  fitting  in  to 
the  overall  COTS  architecture.  These  different  functional  applications  would  be  built  on 
the  overall  COTS  architecture,  invoking  services  provided  by  the  COTS  system. 

2.  System  Architecture: 

The  Task  Force  encourages  the  development  of  a  hierarchical  (layered) 
architecture  for  the  objective  system,  similar  to  the  style  of  the  Common  Operating 
Environment  (COE),  in  which  lower  level  modules  provide  services  to  higher  level 
modules.  These  lower  level  modules  should  be  common  to  all  services  and  functions. 
Simple  examples  are  database  services,  report  generation  services,  operating  system 
services,  communication  protocols  and  message  system  services.  At  a  higher  level,  there 
should  be  functions  that  are  common  to  all  Services,  such  as  in-processing,  separation, 
retirement,  and  transfer  to  reserves.  Some  of  these  may  need  parameters  that  enable 
tailoring  for  differences  in  Service  operating  procedures,  such  as  the  time  period  for  an 
enlistment,  or  time  required  for  notice  of  intent  to  separate.  These  functions  can  then 
provide  services  to  other  functions  that  are  Service-unique. 

Careful  thought  needs  to  be  given  to  the  appropriate  hierarchy  of  services.  A 
good  example  of  a  poor  choice  was  highlighted  in  the  discussion  of  Service-unique 
requirements  for  promotion  boards.  All  Services  have  a  requirement  to  support 
promotion  boards,  but  promotion  board  support  is  not  a  fundamental  service.  All 
promotion  boards  (and  probably  selection  boards  for  Service  schools  —  and  very  likely 
similar  selection  committees  in  civilian  companies)  have  certain  generic  requirements. 
Each  needs  to  search  the  database  for  records  that  meet  certain  criteria  to  select  those 
candidates  that  are  eligible.  For  instance,  there  may  be  a  need  to  order  the  records  based 
on  a  simple  criterion,  such  as  date  of  rank,  while  also  allowing  the  assignment  of  numeric 
ratings  for  various  activities  so  that  a  rank  ordered  list  can  be  created.  Performing  the 
analyses  from  the  generic  to  the  specific  will  suggest  the  hierarchy  of  services.  Failure  to 
do  so  will  lead  to  many  more  unique  modules  than  are  necessary.  In  the  worst  case,  there 
would  be  a  separate  system  for  each  Service,  simply  operating  on  the  same  platform 
(which  is  clearly  not  what  is  intended). 
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Such  an  approach  is  critical  in  order  to  avoid  the  pitfall  of  having  the  new 
objective  system  crack  under  the  weight  of  requirements.  Each  of  the  Services’  personnel 
and  payroll  systems  was  itself  a  major  software  undertaking,  largely  due  to  the  extensive 
set  of  requirements.  By  incorporating  all  the  requirements  of  two  major  functions  from 
four  Services  and  the  reserves  without  a  well-designed  architecture,  the  objective  system 
could  become  hopelessly  flawed. 

The  Task  Force  recognizes  that  there  is  a  trade-off  between  the  Services’  desires 
for  the  preservation  of  existing  processes  that  have  provided  functionality  over  perhaps 
many  years,  on  the  one  hand,  and  the  potential  for  savings  in  system  automation,  on  the 
other.  By  pursuing  the  hierarchical  analyses  just  outlined,  the  presumption  will  be  that 
improved  functionality  and  cost  savings  will  be  pursued  where  possible,  and  Service- 
unique  functions  supported  only  when  necessary.  The  effect  is  to  reverse  the  current 
presumption  in  favor  of  existing  (and  future)  Service-unique  systems.  The  Task  Force 
views  this  as  a  critical  step  in  ensuring  a  solution  to  the  problems  outlined  in  Section  H. 

3.  Supporting  Infrastructure: 

Task  Force  members  agreed  that  the  objective  system  must  meet  DoD  technical 
guidelines  and  that  an  underlying  infrastructure  must  be  available  to  achieve  maximum 
benefits  from  available  technology.  The  system  platform(s)  must  clearly  be  powerful 
enough  to  provide  the  required  services  of  the  core  system  at  acceptable  performance 
levels.  The  complete  infrastructure  includes  hardware,  operating  systems,  databases,  and 
networks.  For  the  objective  system,  these  components  should  meet  the  following 
technical  criteria: 

•  all  components  must  comply  with  the  DISA-specified  Common  Operating 
Environment  (COE)  guidelines; 

•  hardware  and  components  must  be  platform  independent; 

•  DoD  standard  data  definitions  must  be  used; 

•  Commercial  Off  The  Shelf  (COTS)  support  software  and  tools  should  be  used 
whenever  possible,  in  addition  to  applications;  and 

•  software  development  must  be  modular. 

Task  Force  members  are  aware  that  decisions  made  today  in  purchasing  systems 
will  determine  (or  possibly  limit)  the  capability  to  comply  with  future  requirements.  If 
the  Services,  in  fielding  their  current  Service-unique  capabilities,  purchase  COE- 
compliant  platform-independent  components,  the  cost  of  this  basic  infrastmcture  will  not 
be  wasted  because  it  can  be  used  to  implement  future  requirements.  Investment  in  this 
modem  infrastmcture  is  required  to  achieve  high  performance  benefits  for  the 
Department,  independent  of  the  need  for  a  common  military  personnel  management 
system. 
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C.  Programmatic  Issues. 

Task  Force  members  agreed  that,  for  a  number  of  reasons,  the  programmatic 
issues  were  among  the  most  difficult  to  resolve.  These  include  a  schedule  for  a  common 
system;  transition  strategies,  including  impacts  on  current  Service  programs;  organization 
and  management  structures;  and  program  funding. 

1.  IOC: 

Task  Force  members  and  Advisors  agreed  that  an  Initial  Operating  Capability 
date  of  2001  was  both  reasonable  and  feasible,  assuming  acceleration  of  the  process  for 
defining  joint  requirements.  This  should  be  viewed  as  a  “not  later  than”  date,  and 
opportunities  to  advance  the  schedule  should  be  pursued  whenever  they  present 
themselves.  An  earlier  date  may  also  be  based  on  an  initial  operating  capability  which 
represents  some  subset  of  the  full  set  of  DoD  functional  requirements. 

2.  Current  Programs: 

The  more  difficult  issues  include  consideration  of  current  Service  personnel 
system  programs  and  how  to  best  maintain  support  while  deliberately  and  efficiently 
moving  to  the  objective  system.  Today,  there  are  seven  distinct  major  modernization 
efforts  taking  place  in  the  area  of  core  military  personnel  management  systems; 

•  the  Army  consolidated  (active  and  reserve)  personnel  database,  which 
consolidates  and  replaces  four  existing  Army  databases; 

•  the  Army  active  personnel  field  system,  which  replaces  the  current  Army 
active  field  system; 

•  the  personnel  module  of  the  Army  reserve  component  system,  which  replaces 
two  current  Army  personnel  field  systems; 

•  the  Navy  consolidated  personnel  (active  and  reserve)  database,  which 
consolidates  and  replaces  three  existing  Navy  databases; 

•  the  Navy  consolidated  personnel  (active  and  reserve)  field  system,  which 
consolidates  and  replaces  four  existing  field  systems; 

•  the  Air  Force  modernization  of  their  already  consolidated  personnel  (active 
and  reserve)  database;  and 

•  the  Air  Force  modernization  of  their  already  consolidated  personnel  (active 
and  reserve)  field  system. 
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The  Army  active  system,  SIDPERS-3,  is  currently  expected  to  begin  fielding  early 
in  FY  97.  The  Navy  and  Air  Force  database  modernization  efforts  are  on  a  common  track 
and  are  closely  linked  to  existing  OSD-led  joint  requirements  effort  —  both  are  expected 
to  incorporate  standard  data  and  have  a  significant  common  core. 

The  relative  immaturity  of  the  Service  personnel  management  system 
modernization  programs,  and,  in  particular,  the  new  start  being  embarked  upon  by  the 
Navy,  create  a  unique  window  of  opportunity  to  aggressively  move  to  a  common  system 
now.  The  Task  Force  recommendations  regarding  the  existing  Service  programs  are 
aimed  at  seizing  this  opportunity. 

3.  Program  Management  and  Organization: 

The  Task  Force  strongly  believes  that  defining  and  implementing  the  right 
management  structure  is  one  of  the  major  critical  success  factors  for  this  program. 
Accordingly,  we  believe  that  it  is  implicit  in  our  charter  that  we  address  this  issue  and 
make  recommendations,  based  on  our  collective  knowledge  and  experience. 

In  order  to  ensure  success  of  the  overall  program,  an  organizational  structure  must 
be  put  in  place  that  will  meet  the  following  criteria: 

•  allows  for  effective  and  complete  definition  of  functional  requirements  in  a 
joint  environment  that  maximizes  participation  from  the  entire  personnel 
community; 

•  provides  a  continuing  mechanism  for  integration  and  coordination  of 
maintenance  activities  and  proposed  modifications; 

•  provides  for  continuity  of  support  for  military  personnel  and  pay  management 
while  the  objective  system  is  in  development  (in  general); 

•  ensures  the  proper  balance  between  efforts  and  resources  required  to  develop 
and  implement  the  objective  system,  as  the  first  priority,  and  efforts  and 
resources  to  provide  critical  interim  support  through  existing  systems  (in 
particular);  and 

•  provides  clear  lines  of  authority  and  responsibility  necessary  to  execute  the 
program,  while  ensuring  that  the  program  remains  responsive  to  the  Services 
who  are  the  ultimate  (primary)  customers  for  the  system. 

Following  extensive  discussion  with  Service  and  OSD  Advisors,  the  Task  Force 
concluded  that  a  three-element  organizational  structure  will  best  meet  these  criteria. 

•  Steering  Committee.  A  new  Steering  Committee  would  be  established,  consisting  of 
the  Assistant  Deputy  Chiefs  of  Staff  for  Personnel  (ADCSPERs)  from  the  Services, 
and  senior  representatives  from  OUSD(P&R),  OASD(Reserve  Affairs),  DFAS,  and 
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the  Joint  Staff.  This  Steering  Committee  would  set  overall  priorities,  and  provide 
advice  and  recommendations  to  the  USD(P&R)  and  the  program  office  (JR&IO)  on 
program  execution  throughout  the  system  life  cycle.  Chairmanship  of  the  Steering 
Committee  would  rotate  annually  among  the  four  Service  ADCSPERs. 

•  Joint  Requirements  and  Integration  Office.  A  Joint  Requirements  and  Integration 
Office  (JR&IO),  reporting  to  the  OUSD(P&R),  would  have  overall  responsibility  for 
development  and  maintenance  of  system  requirements  as  well  as  for  program 
execution.  This  office  would  also  coordinate  the  development  efforts  of  the 
Executive  Agents  and  monitor  program  progress.  The  JR&IO  should  review  the 
program  with  the  Steering  Committee  on  a  monthly  basis  initially,  and  at  least 
quarterly  thereafter  (as  determined  by  the  Steering  Committee). 

•  Executive  Agents/Services/DFAS.  The  Executive  Agents  would  accomplish  all 
system  development  and  maintenance  work,  with  program  management  and 
acquisition  responsibilities  for  their  designated  systems.  In  addition,  the  Services 
would  have  total  responsibility  for  their  fielded  systems.  Consistent  with  DoD  policy, 
the  Defense  Finance  and  Accounting  Service  (DFAS)  would  continue  to  have 
operational  responsibility  for  the  fielded  pay  portions  of  the  objective  system. 

Disagreements  that  arise  during  the  project  should  be  addressed  first  by  the 
existing  Joint  Integration  Group  (JIG).  If  the  JIG  cannot  resolve  an  issue,  it  should  be 
referred  to  the  Steering  Committee  for  its  reconmiendation,  and  then  to  the  existing 
Policy  Review  Committee.  The  Policy  Review  Committee  should  meet  as  required  to 
resolve  those  issues. 

The  objective  system  should  adhere  to  all  DoD  acquisition  life-cycle 
requirements,  including  appropriate  oversight  by  the  Major  Automated  Information 
System  Review  Council  (MAISRC).  Within  DoD,  the  ASD(C3I),  through  the  MAISRC, 
supervises  the  acquisition  management  responsibilities  of  all  major  information  systems. 
Since  DoD  policies  have  recently  been  rewritten  to  streamline  the  layers  of  oversight,  the 
Executive  Agents  should  be  designated  as  Joint  Program  Managers  for  their  elements  of 
the  objective  system  and  report  to  the  MAISRC  through  their  respective  Service 
acquisition  hierarchies,  with  full  participation  and  coordination  from  the  JR&IO  to  ensure 
that  the  full  intent  of  the  common  system  is  implemented.  The  JR&IO  should  be  the 
sponsor  for  all  MAISRC  reviews. 

The  Task  Force  strongly  believes  that  the  JR&IO  must  be  organized  as  soon  as 
possible,  with  a  target  date  of  October  31, 1996.  Since  it  normally  takes  up  to  a  year  to 
appoint  a  new  SES,  we  recommend  that  the  Director  (IM)  in  OUSD(P&R)  be  appointed 
as  acting  or  interim  director,  in  order  to  ensure  a  smooth  transition  from  current  activities 
to  the  accelerated,  more  comprehensive  program  outlined  in  this  report. 
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IV.  Recommendations. 


Major  recommendations  and  the  underlying  rationale  are  provided  below. 
(Additional  information,  to  include  implementation  guidelines,  criteria,  and  supporting 
rationale  and  recommendations,  can  be  found  in  Section  III.) 

A,  Recommendation  on  the  Objective  System. 

The  Task  Force  members  and  Advisors,  along  with  the  Under  Secretary 
(Comptroller),  the  Under  Secretary  (Personnel  and  Readiness)  and  the  Assistant  Secretary 
(Command,  Control,  Communications  and  Intelligence),  reached  consensus  that  the 
Department  should  move  to  a  single  all-Service  and  all-component,  fully  integrated 
personnel  and  pay  system,  with  an  Initial  Operating  Capability  of  2001  or  earlier. 

The  objective  military  personnel  management  system  should  be  based  on  a 
common  core  set  of  functional  modules  that  accommodates  Service  specific  requirements 
as  needed.  This  common  system  would  consist  of  three  sets  of  modules: 

Set  1  -  truly  “common”  modules  which  are  used  by  all  Services  (and  all 
components)  for  those  functions  which  can  be  identical; 

Set  2  -  “multi-Service”  modules  which  have  a  common  core  of  functionality,  but 
include  limited  variant  processes  for  each  of  the  Services  as  necessary  and 
appropriate,  to  be  used  by  all  Services  for  those  functions  which  are  very  similar, 
but  not  identical;  and 

Set  3  -  “Service-unique”  modules  for  those  functions  which  require  unique 
processes  for  any  or  all  of  the  Services. 

For  each  Service,  the  fielded  system  would  include  all  of  Set  1,  all  (or  most)  of  Set  2,  and 
its  subset  of  Set  3.  Taken  together.  Sets  1  and  2  should  comprise  the  majority  of  each 
fielded  system  (in  excess  of  80  per  cent  as  a  target),  with  Set  3  (Service-unique)  being  a 
relatively  small  component.  This  approach  is  consistent  with  the  emerging  results  of  on¬ 
going  efforts  by  the  Personnel  and  Readiness  Military  Personnel  Management  Joint 
Working  Group  and  the  Services. 

The  Task  Force  defines  a  “fully  integrated  personnel  and  pay  system”  as  one 
which  meets  the  following  criteria:  one-time  entry  of  data  that  automatically  triggers  all 
personnel  and  pay  transactions;  one-stop  shopping  for  personnel  and  pay  transactions  for 
the  Service  members  and  managers;  one  set  of  fully  automated  edits  per  function;  and 
processing  that  does  not  require  manual  reconciliation  or  intermediate  data  entry.  From  a 
logical  standpoint,  each  Service  would  have  a  single  personnel  and  pay  system  with  a 
single  database.  From  a  technical  or  physical  standpoint,  modem  technology  and  modular 
system  development  approaches  may  result  in  a  system  with  separate  (and  possibly 
distributed)  modules  and/or  automatically  replicated/synchronized  database  components. 
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But  the  user  must  see  a  single,  fully  integrated  system,  providing  combined  personnel  and 
pay  functionality. 

By  its  recommendation  for  a  common  system,  the  Task  Force  is  not 
recommending  a  centrally  operated  or  managed  system.  While  the  development  and 
maintenance  functions  for  the  software  should  be  integrated  and  consolidated,  ownership, 
operation,  and  management  of  the  fielded  systems  should  remain  with  the  Services. 

B.  Recommendations  on  the  Development  Approach. 

The  preliminary  work  of  the  Personnel  and  Readiness  Joint  Working  Group  for 
Military  Personnel  Management  has  demonstrated  that,  with  full  Service  participation, 
consensus  on  functional  requirements  for  a  common  system  can  be  achieved.  The 
Service  Advisors  to  the  Task  Force  have  confirmed  the  success  of  this  process. 

The  Task  Force  reconunends  an  acceleration  of  the  process  initiated  by  the 
Personnel  and  Readiness  Military  Personnel  Management  Joint  Working  Group  to  define 
functional  requirements  and  pass  them  to  Executive  Agents  for  software  development. 
The  process  of  defining  functional  requirements  must  be  performed  by  the  personnel 
community,  with  full  participation  from  the  Services,  the  Joint  Staff,  the  Defense  Finance 
and  Accounting  Service  (for  pay  integration)  and  OSD.  To  complete  this  process,  the 
Task  Force  recommends  the  “Workshop”  approach  discussed  in  Section  HI  (and  in 
Exhibit  1  at  Appendix  A).  Joint  requirements  should  incorporate,  to  the  maximum  extent 
possible,  best  commercial  practices  as  well  as  best  Service  practices,  with  the  objective  of 
minimizing  Service-unique  requirements  and  maximizing  potential  COTS  utilization. 

The  Task  Force  places  the  selection  of  system  architecture,  which  addresses 
software  and  supporting  infrastructure,  as  a  matter  of  high  priority,  concurrent  with 
defining  functional  requirements.  To  this  end,  the  Task  Force  recommends  pursuit  of  a 
COTS  system  as  the  basis  of  the  objective  system.  As  a  first  step  in  this  direction,  the 
Task  Force  recommends  that  a  COTS  Analysis  and  Evaluation  Plan  be  developed  and 
approved.  Guidance  for  this  plan  is  contained  in  Section  III  (see  COTS  Selection).  A 
decision  on  a  specific  COTS  package  and/or  development  approach  using  Computer 
Assisted  Software  Engineering  tools  should  be  made  early,  preferably  within  three 
months  of  the  establishment  of  the  JR&IO.  The  Task  Force  further  recommends  the 
development  of  a  hierarchical  (layered)  system  architecture,  and  selection  of  supporting 
infrastructure  in  accordance  with  the  DISA  Common  Operating  Environment  as  also 
detailed  in  Section  HI. 

C.  Recommendations  on  a  Transition  Strategy. 

A  detailed  implementation  plan  and  schedule  must  be  developed  for  each  Service 
that  provides  for  a  smooth  and  timely  transition  to  the  objective  system.  These  schedules 
cannot  be  defined  in  complete  detail  until  the  process  of  requirements  definition  has 
progressed  further.  Assuming  the  acceleration  of  requirements  definition  and  software 
development  as  outlined  above,  these  detailed  implementation  plans  should  be  in  place 


24 


within  one  year  of  the  initiation  of  the  accelerated  requirements  development  effort. 
Pending  development  of  the  detailed  implementation  plans,  the  Task  Force  recommends 
the  following  high-level  strategy. 

Army.  The  software  development  phase  of  SIDPERS-3  is  essentially  complete. 
Fielding  of  SIDPERS-3  should  continue  as  planned  within  the  Army,  giving  the  Army  a 
much  needed  modernized  infrastructure.  The  hardware  deployed  to  support  SIDPERS-3 
should  be  platform-independent  and  should  also  accommodate  the  software  of  the 
objective  system.  Maximum  use  of  SIDPERS-3  software  should  be  made  in  fielding  an 
RCAS  personnel  module,  while  development  of  new  personnel  software  for  RCAS 
should  be  done  as  part  of  the  objective  system,  which  should  support  both  active  and 
reserve  Army  components.  Any  future  purchases  of  hardware  to  support  the  Army 
reserve  components  should  ensure  that  the  objective  system  software  can  also  be 
accommodated. 

Navy.  The  Navy  is  at  the  early  stages  of  development  of  their  modernized 
systems  (both  field  level  and  database).  It  is  the  best  positioned  of  the  Services  to  take 
full  advantage  of  the  objective  system.  The  Navy  should,  therefore,  refocus  its  primary 
effort  on  developing  the  objective  system.  Without  materially  delaying  its  accelerated 
development  and  deployment  schedule  for  critically  needed  NSIPS  capabilities,  current 
NSIPS  efforts  should  be  broadened  to  encompass  the  objective  system  requirements  as 
they  are  developed  by  the  JR&IO.  Wherever  possible,  pressing  NSIPS  requirements 
should  be  satisfied  through  early  incremental  fielding  of  objective  system  modules.  The 
Navy  should  continue  its  role  as  Executive  Agent  for  the  field  level  component  of  the 
objective  system. 

Air  Force.  The  Air  Force  is  near  completion  of  the  modernization  of  its  corporate 
tier  and  system  architecture.  This  effort  uses  modified  COTS  and  may  have  relevance  for 
the  objective  system.  The  Air  Force  should  not  proceed  with  independent  modernization 
of  its  field  level  system,  but  should  refocus  on  implementing  and  adopting  the  objective 
system.  The  Air  Force  should  continue  its  role  as  Executive  Agent  for  the  corporate  tier 
and  system  architecture  for  the  objective  system. 

Marine  Corps.  The  Marine  Corps  has  not  planned  a  major  modernization  effort, 
but  is  planning  several  enhancements  to  its  existing  system.  Except  for  the  year  2000  fix, 
which  must  be  completed  prior  to  2000,  the  Marine  Corps  enhancements  should  be 
identified  as  requirements  for  the  objective  system  and  should  not  be  undertaken 
separately.  The  Marine  Corps  should  thus  refocus  its  functional  and  technical 
enhancement  plans  on  the  objective  system.  The  Marine  Corps  representatives  in  the 
JR&IO/JWG  should  further  take  the  lead  role  in  developing  those  functional 
requirements  for  the  objective  system  that  pertain  to  the  integration  of  pay  and  personnel 
functionality. 

In  short,  the  Task  Force  recommends  that  all  planned  new  modernization  efforts 
be  refocused  on  the  objective  system. 
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D.  Recommendations  on  Management. 

An  effective  management  structure  is  essential  to  ensure  effective  guidance  and 
management  of  the  development  and  maintenance  of  the  objective  system.  The  structure 
should  further  ensure  that  the  personnel  community,  in  OSD  and  the  Services,  maintains 
control  of  both  the  definition  of  requirements  and  the  maintenance  functions. 

The  Task  Force  has  elicited  complete  agreement  from  the  personnel  community 
and  the  USD(Comptroller)  that  the  objective  system  should  be  a  fully  integrated 
personnel  and  pay  system.  Within  DoD,  however,  there  is  currently  no  appropriate 
structure  to  oversee  and  manage  the  joint  development  of  combined  military  pay  and 
personnel  management  automation  support. 

Accordingly,  a  three-element  management  structure  is  recommended: 

Program  Office  (JfR&lO):  The  Task  Force  recommends  that  the  current 
USD(P&R)  Information  Management  organization  be  restructured  and  designated  as  the 
Joint  Requirements  and  Integration  Office  (JR&IO),  as  part  of  a  field  activity  reporting  to 
the  USD(P&R).  The  responsibilities  of  this  office  should  include  overall  program 
authority,  as  well  as  defining  and  maintaining  a  set  of  common-core  and  Service-specific 
requirements  for  implementation  by  the  Executive  Agents.  (Staff  increases  will  be 
necessary  to  fulfill  these  responsibilities.)  The  JR&IO  should  be  headed  by  an  SES-level 
civilian  Director. 

As  soon  as  possible  (target  first  quarter,  FY97),  the  JR&IO,  augmented  by  the 
Military  Personnel  Management  Joint  Working  Group,  should  assume  full  responsibility 
for  defining  the  requirements  for,  and  directing  the  implementation  of,  the  objective  all- 
Service  and  all-component  fully  integrated  personnel  and  pay  system,  under  charter  from 
the  Deputy  Secretary  of  Defense.  In  addition  to  the  existing  responsibilities  of  the 
OUSD(P&R)  Information  Management  Office,  JR&IO  responsibilities  should  include: 

•  reviewing  and  defining  all  functional  requirements  for  the  objective  system; 

•  coordinating  the  efforts  of  the  Executive  Agents; 

•  developing  performance  criteria  for  and  evaluating  performance  of  the 
objective  system; 

•  analyzing  reasonable  policy  alternatives  for  enhanced  functionality  and 
savings; 

•  defining  requirements  for,  and  programming  all  funds  related  to,  developing 
and  maintaining  the  objective  system  in  the  PPBS  cycle,  in  coordination  with 
the  Executive  Agents; 

•  ensuring  the  successful  fielding  by  the  Services  of  the  objective  system;  and 

•  preparing  an  annual  report  to  the  Deputy  Secretary  of  Defense  on  what 
progress  is  being  made  in  development  of  the  objective  system. 

The  JR&IO  must  ensure  that  the  common  core  meets  functional  requirements  and 
minimizes  wasteful  duplication  of  systems  development.  This  means  that  it  should 
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operate  under  the  explicit  guideline  of  minimizing  the  need  for  Service-unique  functions, 
and  hence  maximizing  the  common  core.  The  charter  should  state  that  the  Services  must 
make  the  case  for  separate  requirements  on  a  case-by-case  basis  as  the  office  goes  through 
the  135  nodes  of  military  personnel  management.  The  JR&IO  should  coordinate  with  the 
JROC  to  ensure  that  the  objective  system  continues  to  meet  the  needs  of  the  CINCs,  as 
well  as  the  Services  and  OSD.  The  JR&IO  should  also  serve  as  the  coordinating  point  for 
integrating  policy  between  and  among  OSD  functional  representatives  of  the  principal 
staff  assistants,  the  Services,  and  technical  representatives  in  OSD  and  the  Defense 
Agencies. 

As  mentioned  above,  the  JR&IO  staff  should  be  augmented  by  the  Joint  Working 
Group  during  the  initial  phase  of  requirements  definition,  to  fully  define  requirements  for 
the  entire  military  personnel  management  function,  following  the  “workshop”  approach 
described  in  Section  III  (and  Exhibit  1  in  Appendix  A).  The  Joint  Working  Group  should 
include  full-time  representation  from  all  Service  components,  the  Joint  Staff,  OUSD 
(Personnel  and  Readiness),  and  the  Defense  Finance  and  Accounting  Service.  After  the 
initial  phase  is  completed,  the  Joint  Working  Group  should  be  eliminated  and  the  office 
should  be  maintained  at  the  minimum  size  sufficient  to  ensure  that  maintenance, 
enhancements  and  future  modernization  are  effectively  managed  in  a  joint  environment. 

Steering  Committee:  On  a  monthly  basis  initially,  and  not  less  than  quarterly,  the 
JR&IO  should  review  the  program  with  a  Steering  Committee  composed  of  the  Assistant 
Deputy  Chiefs  of  Staff  for  Personnel  (ADCSPERs)  from  the  Services,  and  senior 
representatives  from  OUSD(P&R),  OASD(Reserve  Affairs),  DFAS,  and  the  Joint  Staff. 
Chairmanship  of  the  Steering  Conunittee  should  rotate  annually  among  the  four  Service 
ADCSPERs,  with  initial  chairmanship  falling  to  the  Army.  This  Steering  Committee 
should  set  overall  priorities,  and  provide  advice  and  recommendations  to  the  USD(P&R) 
and  the  JR&IO  regarding  program  execution  throughout  the  life  cycle  process  of 
requirements  definition,  software  acquisition/development,  hardware  acquisition,  fielding 
and  follow-on  maintenance  functions.  The  Steering  Committee  should  issue  an  annual 
written  report  to  the  Deputy  Secretary  of  Defense  providing  the  committee’s  assessment 
of  the  progress  of  the  program. 

Executive  Agents/Services.  All  program  management,  system  development,  and 
maintenance  should  be  done  by  the  Executive  Agent  program  management  offices.  The 
Executive  Agents  should  also  be  responsible  for  defining  the  resources  required  for  them 
to  fulfill  their  responsibilities.  Formal  agreements  with  Executive  Agents  should  be 
signed,  with  the  understanding  that  the  agents  report  to  the  Joint  Requirements  and 
Integration  Office  for  development  and  maintenance  of  these  systems.  The  Services 
should  prepare  BES  documentation  on  the  basis  of  guidance  issued  in  the  POM  cycle  and 
would  be  responsible  for  acquisition  of  all  systems. 

E.  Recommendations  on  Funding. 

Beginning  in  FY  97,  investment  funds  will  be  required  to  define  functional 
requirements  and  design,  develop,  and  test  software  for  the  objective  system.  The  Task 
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Force  recommends  that  USD(Comptroller)  immediately  take  steps  to  address  the  funding 
shortfalls  for  FY  97  and  FY  98.  (Exhibit  1  of  Appendix  A  provides  an  estimate  of  funds 
required  for  the  development  of  joint/common  requirements  and  for  the  development  of 
OSD  and  Joint  Staff  requirements  and  the  associated  software  development.)  Additional 
funding  must  also  be  identified  from  the  Services  to  support  development  of  their  unique 
functional  requirements.  Personnel  and  investment  funds  should  be  allocated  to  the  Joint 
Requirements  and  Integration  Office.  (This  will  require  direction  from  the  Deputy 
Secretary.) 


28 


V.  Assignment  of  Responsibilities. 


To  ensure  that  the  recommendations  of  the  Task  Force  are  carried  out  in  a  timely 
manner,  this  section  identifies  the  specific  actions  that  should  be  taken,  when,  and  by 
whom,  consistent  with  recommendations  in  Section  IV. 

A.  Establish  the  Joint  Requirements  and  Integration  Office.  By  October  31, 
1996,  the  Office  of  the  Under  Secretary  (Personnel  and  Readiness),  with  support 
from  the  Services  and  the  Office  of  the  Under  Secretary  (Comptroller),  should 
prepare  a  Deputy  Secretary  of  Defense  charter  for  the  Joint  Requirements  and 
Integration  Office  as  part  of  a  field  activity  of  the  OUSD(P&R).  (As  an 
alternative,  it  may  be  appropriate  to  revise  the  USD(P&R)  Charter  to  include  the 
JR&IO  and  its  responsibilities.)  Since  it  normally  takes  up  to  a  year  to  appoint  a 
new  SES,  we  recommend  that  the  Director  (IM)  in  OUSD(P&R)  be  appointed  as 
acting  or  interim  director,  in  order  to  ensure  a  smooth  transition  from  current 
activities  to  the  accelerated,  more  comprehensive  program  outlined  in  this  report. 
Also  by  October  31, 1996,  the  charter  of  the  existing  Joint  Working  Group  should 
be  revised  and  extended  as  required  to  augment  the  JR«&IO  during  the 
requirements  definition  period. 

B.  Establish  the  Steering  Committee.  By  October  31,1 996,  the  Office  of  the 
Under  Secretary  (Personnel  and  Readiness),  with  support  from  the  Services,  the 
Office  of  the  Under  Secretary  (Comptroller),  and  the  Office  of  the  Assistant 
Secretary  (Command,  Control,  Communications,  and  Intelligence),  should 
establish  and  charter  the  Steering  Committee  to  set  overall  priorities  and  provide 
advice  and  recommendations  to  the  USD(P&R)  and  the  Joint  Requirements  and 
Integration  Office  both  for  development  and  maintenance  functions. 

C.  Acquire  Funds.  The  Office  of  the  Under  Secretary  (Personnel  and 
Readiness),  with  support  from  the  Office  of  the  Under  Secretary  (Comptroller), 
should  prepare  necessary  documents  to  acquire  funds  to  support  the  definition  of 
requirements  and  design,  development,  and  testing  of  software  for  the  objective 
system,  to  begin  in  October  of  1996.  (The  Task  Force  recommends  that  the 
funding  be  allocated  to  the  Joint  Requirements  and  Integration  Office.) 

D.  Prepare  Requirements  Definition  Schedule.  By  January  31, 1997,  the  Joint 
Requirements  and  Integration  Office,  through  the  Office  of  the  Under  Secretary 
(Personnel  and  Readiness),  should  submit  to  the  Steering  Committee  a  schedule 
for  completing  requirements  definition  in  time  for  an  IOC  of  the  objective  system 
by  or  before  2001.  The  schedule  should  include  the  schedule  of  workshops, 
prioritized  to  ensure  the  maximum  potential  for  early  deployment. 

E.  Charter  Executive  Agents.  By  October  31, 1996,  the  Office  of  the  Under 
Secretary  (Personnel  and  Readiness),  in  coordination  with  the  Services,  the  Office 
of  the  Under  Secretary  (Comptroller),  and  the  Office  of  the  Assistant  Secretary 
(Command,  Control,  Communications,  and  Intelligence),  should  expand  the 
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existing  charters  of  the  Executive  Agents  to  design,  develop,  and  test  the  software 
for  the  objective  system. 

F.  Prepare  Software  Design,  Development,  and  Testing  Plan  and  Schedule. 

By  November  30, 1996,  the  Executive  Agent  Program  Managers,  through  the 
Director  of  the  Joint  Requirements  and  Integration  Office  should  submit  to  the 
Steering  Committee  a  plan  and  initial  schedule  for  design,  development,  and 
testing  of  software.  These  plans  should  include  preparation  of  appropriate 
acquisition  documents,  as  required. 

G.  Support  the  Functional  Workshops.  The  process  for  defining  functional 
requirements  for  the  objective  system  requires  full  participation  from  functional 
experts  throughout  the  personnel  community  and,  for  pay  integration  functions, 
the  finance  community.  The  Services,  the  Joint  Staff,  and  the  Defense  Finance 
and  Accounting  Service  should  provide  appropriate  subject  matter  experts  to  the 
workshops  as  required. 

H.  Prepare  Implementation  Plans.  By  September  30, 1997,  the  Services  must 
submit  to  the  Under  Secretary  (Personnel  and  Readiness)  and  the  Assistant 
Secretary  (Command,  Control,  Communications,  and  Intelligence)  individual 
implementation  plans  for  moving  to  the  objective  system. 

I.  Complete  COTS  Review  and  Analysis.  By  January  31, 1997,  the  review  and 
analysis  of  COTS  candidates  should  be  completed  in  accordance  with  an  approved 
COTS  Analysis  and  Evaluation  Plan.  An  Integrated  Process  Team  (IPT), 
established  and  coordinated  by  the  JR&IO,  (including  the  two  Executive  Agents 
and  representatives  from  OASD(C3I),  the  Services,  and  DFAS)  should  develop 
and  implement  this  plan  and  agree  on  a  common  approach  for  the  use  of  COTS 
software  in  the  objective  system.  The  review  and  analysis  should  consider  and 
build  on  the  studies  already  under  way  by  the  Air  Force  and  Navy. 
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DESCRIPTION  OF  APPENDICES 


All  appendices  (A  through  H)  and  the  Final  Report  are  located  on  the  Internet  at 

http://www.mpm.osd.niil 

Appendices  A  through  D  included  in  this  document  for  the  convenience  of  the  reader 
Appendix  A;  Exhibits 

This  appendix  contains  the  documents  referenced  in  the  DSB  Task  Force  Final  Report.  They 
include: 

A-1 .  Acceleration  of  Design  and  Development  of  Common  Military  Personnel/Pay 
Management  Objective  System  -  Resources  Required  (revised  8/31/96) 

A-2.  Using  COTS  Software  In  Systems  Development  from  National  Research  Council 
of  Canada,  Institute  for  Information  Technology,  Software  Engineering  Group 
(Copyright  1996) 

A-3.  “Retool  Human  Resources”  and  “HR  App  Meets  Critical  Needs”  articles  from 
Datamation  Journal.  (6/15/95) 

A-4.  Defense  Science  Board  Military  Personnel  and  Pay  System  Task  Force 
Commercial  Off  The  Shelf  (COTS)  Feature  Comparison  Charts  (8/8/96) 

A-5.  Ms.  Padalino’s  memo  with  SYBASE  input  to  the  Defense  Science  Board  Task 
Force  on  Military  Personnel  Information  Management  Report  -  BAFO,  (8/7/96) 

A-6.  Mr.  Selsor’s  memo  with  GRCI  input  to  the  Defense  Science  Board  Task  Force  on 
Military  Personnel  Information  Management  Report  -  BAFO,  (8/7/96) 

A-7.  BG  Pellicci’s  (USA,  Ret)  memo  with  ORACLE  input  to  the  Defense  Science 

Board  Task  Force  on  Military  Personnel  Information  Management  Report  -  BAFO, 
(8/6/96) 

A-8.  Mr.  Larry  Rinderknecht  memo  with  EDS  input  to  the  Defense  Science  Board  Task 
Force  on  Military  Personnel  Information  Management  Report  -  BAFO,  (8/20/96) 

Appendix  B:  Task  Force  Participants 

This  list  contains  the  names,  positions,  and  company  or  government  affiliations  of  the: 
members,  advisors,  executive  secretaries,  and  staff  support  for  the  Defense  Science  Board 
Task  Force  on  Military  Personnel  Information  Management. 

Appendix  C:  Terms  of  Reference 

This  USD  (A&T)  memorandum  dated  February  23, 1996  and  addressed  to  the  Chairman  of 
the  Defense  Science  Board  defines  the  Terms  of  Reference  for  the  Task  Force  on  Military 
Personnel  Information  Management. 

Appendix  D:  Recommendations  Mapped  to  Terms  of  Reference  Tasks 

This  summarizes  the  Task  Force  recommendations  relative  to  the  five  major  issues  defined  in 

the  Terms  of  Reference. 
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Appendix  E;  Agenda 


This  appendix  contains  the  agenda  for  all  meetings  of  the  DSB  Task  Force  on  Military 
Personnel  Information  Management.  The  first  four  meetings  focused  on  defining  and 
gathering  information  for  the  Task  Force  members.  The  last  three  meetings  focused  on 
formulating  and  documenting  conclusions  and  recommendations.  The  meeting  dates  were: 

•  February  22, 1996 

•  March  21-22, 1996 

•  April  29-30, 1996 

•  May  23, 1996 

•  June  26, 1996 

•  July  29, 1996 

•  August  21, 1996 

Appendix  F;  Meeting  Summaries 

This  appendix  provides  summaries  of  each  Task  Force  meeting.  Meeting  dates  and  the  lists  of 
attachments  to  each  summary  are  listed  below: 

F-1.  February  22. 1996  >  -  < 

•  February  Meeting  Summary  (3/22/96)  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

•  Dr.  Salisbury’s  Task  Analysis  Chart 
F-2.  March  21-22. 1996 

•  March  Meeting  Summary  (4/29/96)  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

F-3.  April  29-30. 1996 

•  April  Meeting  Summary  (5/23/96)  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

F-4.  May  23. 1996 

•  May  Meeting  Summary  (6/26/96)  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

•  Dr.  Salisbury  Briefing  Slides  -  Vision/Issues/Problems 
F-5.  June  26. 1996 

•  June  Meeting  Summary  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

•  Dr.  Salisbury  Slides  -  Benefits/Objectives  of  Cormnon  Core  System 
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Appendix  F;  Meeting  Summaries  (cont’d) 


F-6.  July  29. 1996 

•  July  Meeting  Summary  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

F-7.  August  21.  1996 

•  August  Meeting  Summary  &  Attachments: 

•  Attendance  Sheet 

•  Agenda 

Appendix  G;  Correspondence 

Memoranda,  letters,  and  other  correspondence  originating  from,  addressed  to,  or  commenting 
on  the  DSB  Task  Force  are  contained  in  this  appendix.  Attachments  referenced  are  generally 
included  elsewhere  in  Appendices  E,  F,  and  H. 

G-1 .  Mr.  Dorn’s  memorandum  to  the  Services’  Assistant  Secretaries  (M&RA)  and  USD(C), 
(2/7/96) 

SUBJECT:  DSB  Task  Force  on  Military  Personnel  Management 

G-2.  Dr.  Salisbury’s  letters  to  Task  Force  Members,  (2/14/96) 

SUBJECT:  Welcome/First  Meeting 

G-3.  Mr.  Kaminski’s  memorandum  to  DSB  Chairman,  (2/23/96) 

SUBJECT:  Terms  of  Reference  --DSB  Task  Force  on  Military  Personnel  Information 
Management 

G-4.  Mr.  Janak’s  letter  to  Dr.  Salisbury,  (3/12/96) 

SUBJECT:  DSB  Task  Force  on  Military  Personnel  Information  Management 

G-5.  Dr.  Salisbury’s  letters  to  Briefers,  (3/14/96)  -  RADM  Gauss,  A1  Munson  (TRW), 

RADM  Froman  (J-1),  Richard  Keevey  (DFAS),  BG  Smith,  Mr.  Patel  (TRW),  Jeff  Carr 
(PeopleSoft),  Col  Keller,  BG  Pellicci  (ORACLE),  and  Michael  Cavander  (EDS) 
SUBJECT:  Briefing  Guidelines 

G-6.  Ms.  St.  Claire’s  note  to  DSB  Participants,  (3/14/96) 

SUBJECT:  Read- Ahead  for  March  21-22  Meeting  of  the  DSB  Task  Force 

G-7.  Dr.  Dahlman’s  note  to  Dr.  Salisbury,  (3/27/96) 

SUBJECT:  Suggestions  for  DSB/MPIM 

G-8.  Ms.  St.  Claire’s  note  to  DSB  Participants,  (4/19/96) 

SUBJECT:  Task  Force  Meeting  of  April  29/30  (Read- Ahead) 
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Appendix  G;  Correspondence  (cont’d) 


G-9.  Ms.  St.  Claire’s  note  to  DSB  Participants,  (4/24/96) 

SUBJECT:  Additional  Read- Ahead  Materials  for  Task  Force  Meeting  of  April  29/30 

G-10.  Dr.  Salisbury’s  letters  to  Task  Force  Members,  (5/8/96) 

SUBJECT:  Three  Task  Force  Working  Groups 

G-1 1.  Dr.  Salisbury’s  letter  to  Mr.  Hamre,  USD(C),  (5/14/96) 

SUBJECT:  Invitation  to  discuss  Personnel/Pay  Integration 

G-1 2.  Ms.  St.  Claire’s  note  to  DSB  Task  Force  on  Military  Personnel  Information 
Management,  (5/15/96) 

SUBJECT:  Read- Ahead  Materials  for  May  23  Meeting 

G-13.  Ms.  St.  Claire’s  note  to  DSB  Members,  (5/17/96) 

SUBJECT:  Summary  Matrices,  (Rev.  5/17/96  -  Changes  were  highlighted  in  yellow) 

G-14.  Ms.  St.  Claire’s  note  to  Joint  Integration  Group,  (5/17/96) 

SUBJECT:  Additional  Information  (e.g.,  process  flows)  for  Task  Force  Members 

G-15.  Mr.  Dougherty’s  (Air  Force  Reserve)  memorandum  to  Ms.  St.  Claire,  (5/21/96) 
SUBJECT:  Additional  Information  for  Task  Force  Members 

G-1 6.  Ms.  St.  Claire’s  note  to  DSB  Task  Force  on  Military  Personnel  Information 
Management,  (5/30/96) 

SUBJECT:  Draft  Statement 

G-17.  Dr.  Salisbury’s  letters  to  Task  Force  Members,  (6/14/96) 

SUBJECT:  Objective  Common  System  for  the  DoD  military  personnel  systems 

G-1 8.  Ms.  St.  Claire’s  note  to  DSB  Task  Force  Members  and  Advisors,  (6/19/96) 
SUBJECT:  Read- Ahead  Materials  for  the  June  26  meeting 

G-1 9.  LtGen  Christmas  memorandum  to  Mr.  Hamre,  USD(C),  (6/24/94) 

SUBJECT:  MPM-21  and  DSB  Task  Force  Activities  on  Personnel  Management 

G-20.  LtGen  Christmas  memorandum  to  Mr.  Dom,  USD(P«&R),  (6/24/94) 

SUBJECT:  MPM-21  and  DSB  Task  Force  Activities  on  Personnel  Management 

G-21.  Mr.  Dorn’s  memorandum  to  LtGen  Christmas,  (7/26/96) 

SUBJECT:  MPM-21  and  DSB  Task  Force  Activities  on  Personnel  Management 

G-22.  Mr.  Janak’s  letter  to  Dr.  Salisbury,  (6/25/96) 

SUBJECT:  Single  Integrated  HR/Payroll  System  for  DoD 
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Appendix  G;  Correspondence  (cont’d) 


G-23.  LtGen  Lukeman’s  (USMC,  Ret)  letter  to  Dr.  Salisbury,  (6/28/96) 

SUBJECT:  Marine  Corps  Perspective 

G-24.  Mr.  Dorn’s  letter  to  Air  Commodore  Winsland,  (7/10/96) 

SUBJECT:  Appreciation  for  Group  Captain  Upham’s  Task  Force  Participation 

G-25.  Ms.  St.  Claire’s  letter  and  note  to  BG  Jack  Pellicci,  USA  (Ret),  (7/10  &  7/1 1/96 
respectively) 

SUBJECT:  ORACLE  questions 

G-26.  BG  Jack  Pellicci’s  (USA,  Ret)  response  to  Ms.  St.  Claire’s  questions,  (7/25/96) 
SUBJECT:  ORACLE  answers 

G-27.  Ms.  St.  Claire’s  note  to  DSB  Task  Force  Participants,  (7/24/96) 

SUBJECT:  Meeting  on  July  29, 1996  at  the  Crystal  City  Sheraton  Hotel  (Read- Ahead) 

G-28.  Dr.  Salisbury’s  letters  to  DSB  Task  Force  Participants  with  two  attachments, 

(7/24/96): 

•  LtGen  Ludwig’s  (USAF,  Ret)  fax,  (7/14/96) 

SUBJECT:  Joint  PMO  Discussion  Briefing 

•  LtGen  Lukeman’s  (USMC,  Ret)  letter,  (7/15/96) 

SUBJECT:  Comments  on  LtGen  Ludwig’s  fax 

G-29.  Mr.  Bemis’  memorandum  to  Dr.  Salisbury,  (7/25/96) 

SUBJECT:  Defense  Science  Board  Task  Force  on  Military  Personnel  Information 
Management 

G-30.  Dr.  Salisbury’s  letter  to  Mr.  Bemis,  (7/29/96) 

SUBJECT:  Defense  Science  Board  Task  Force  on  Military  Personnel  Information 
Management 

G-3 1 .  Dr.  Dahlman’s  note  to  DSB  Task  Force  Members,  (7/26/96) 

SUBJECT:  OSD  Field  Agency 

G-32.  Ms.  St.  Claire’s  note  to  DSB  Task  Force  Participants,  (7/29/96) 

SUBJECT:  Meeting  of  July  29, 1996 

G-33.  Dr.  Salisbury  memorandum  to  DSB  Task  Force  Members,  (7/29/96) 

SUBJECT:  Inputs  for  Draft  Report 

G-34.  Ms.  St.  Claire’s  note  to  DSB  Task  Force  Participants,  (8/15/96) 

SUBJECT:  Next  Meeting  (August  21  Read- Ahead) 
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Appendix  G;  Correspondence  (cont’dl 


G-35.  Brief  and  Final  Observations  provided  to  Dr.  Salisbury  as  input  for  Final  Report: 

G-35.a)  RADM  Gunn’s  memo  with  Navy  input  to  the  Defense  Science 

Board  Task  Force  on  Military  Personnel  Information  Management  Report 
-BAFO,  (8/2/96) 

G-35.b)  MG  Vollrath’s  memo  with  Army  input  to  the  Defense  Science  Board 
Task  Force  on  Military  Personnel  Information  Management  Report 

-  BAFO,  (8/5/96) 

G-35.C)  LtCol  Westcott’s  memo  with  Marine  Corps  input  to  the  Defense 
Science  Board  Task  Force  on  Military  Personnel  Information 
Management  Report  -  BAFO,  (8/6/96) 

G-35.d)  Ms.  Grese’s  memo  with  Air  Force  input  to  the  Defense  Science 

Board  Task  Force  on  Military  Personnel  Information  Management  Report 

-  BAFO,  (8/6/96) 

G-35.e)  BG  Pellicci’s  (USA,  Ret)  memo  with  ORACLE  input  to  the  Defense 
Science  Board  Task  Force  on  Military  Personnel  Information 
Management  Report  -  BAFO,  (8/6/96) 

G-35.f)  Mr.  Selsor’s  memo  with  GRCI  input  to  the  Defense  Science  Board 
Task  Force  on  Military  Personnel  Information  Management  Report  - 
BAFO,  (8/7/96) 

G-35.g)  Ms.  Padalino’s  memo  with  SYBASE  input  to  the  Defense  Science 

Board  Task  Force  on  Military  Personnel  Information  Management  Report 

-  BAFO,  (8/7/96) 

G-35.h)  Mr.  Larry  Rinderknecht  memo  with  EDS  input  to  the  Defense 
Science  Board  Task  Force  on  Military  Personnel  Information 
Management  Report  -  BAFO,  (8/20/96) 

G-36.  Final  Comments  on  Draft  Report  of  the  DSB  Task  Force  on  Military  Personnel 
Information  Management 

G-36.a)  Mr.  Keevey’s  memo  to  Director,  IM,  OUSD  (P&R)  with  DFAS 
comments  (8/27/96) 

G-36.b)  MG  Vollrath’s  memo  to  Chairman,  DSB  Task  Force  on  Military 

Personnel  Information  Management  with  Army  comments  (8/27/96) 
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Appendix  G;  Correspondence  (cont’d) 


G-36.C)  Ms.  Grese’s  letter  to  Dr.  Salisbury  with  Air  Force  comments 
(8/27/96) 

G-36.d)  Ms.  Howell’s  memo  to  Chairman,  DSB  Task  Force  on  Military 

Personnel  Information  Management  with  Marine  Corps  comments 
(8/27/96) 

G-36.e)  RADM  Gunn’s  memo  to  Chairman,  DSB  Task  Force  on  Military 
Personnel  Information  Management  with  Navy  comments 
(8/27/96) 

G-36.f)  RADM  Froman’s  memo  to  OUSD  for  Personnel  &  Readiness  with 
Joint  Staff  comments  (8/28/96) 

G-37.  Army,  Air  Force,  and  Navy  Times  Articles  (7/96)  on  the  Defense  Science  Board  Task 
Force  on  Military  Personnel  Information  Management 


Appendix  H:  Selected  Information  Papers 

The  information  papers  in  this  appendix  were  presented  or  referenced  at  the  DSB  Task  Force 
meetings.  They  include: 

H-1 .  Military  Personnel  and  Readiness  Information  Management  Program  Strategic  Plan 
(Rev.  12/95):  a  summary  of  the  P&R  strategic  plan  prior  to  the  deliberations  of  the 
Task  Force. 

H-2.  Summary  of  Military  Personnel  Information  Management  Issue  (4/17/96) 

H-3.  Questions  and  Answers  from  the  DSB  Task  Force  (4/24/96) 

H-4.  Summary  Services’  Matrices  (Final  Version  7/29/96) 

•  Database/System  Notes 

•  Definitions  of  Functional  Matrix 

•  Definitions  of  Programmatic  Matrix 

•  Definitions  of  Technical  Matrix 

•  Functional  Summary  Matrix  with  Notes 

•  Programmatic  Summary  Matrix  with  Notes 

•  Technical  Summary  Matrix  with  Notes 

•  Services  POM  Summaries 

•  Total  Military  Personnel  Function  Costs  Information  Paper 

•  Acronyms  for  Matrices 
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Appendix  H;  Selected  Information  Papers 


H-5.  Services’  Modernization  Plans  Information  Papers  for  the  May  23  DSB  Task  Force 
Meeting 

•  Army 

.  Navy  (NMPDB  &  NSIPS) 

•  Marine  Corps 

•  Air  Force 

H-6.  Promotion  Process:  Two  Versions  of  Data  Flow  (5/22/96) 

H-7.  Acceleration  of  Design  and  Development  of  Common  Military  Personnel/Pay 
Management  Objective  System  -  Resources  Required  (revised  8/31/96) 

H-8.  Summary  of  Principal  Staff  Assistants  (PSAs)  Information  Management 
Responsibilities  (2/95) 

H-9.  The  Planning,  Programming,  &  Budgeting  System  (PPBS)  (4/24/96) 

H-10.  Acquisition  Process  for  Major  Automated  Information  Systems  (MAIS)  (4/24/96)  and 
Defense  Acquisition  Policy  (Executive  Summary  2/28/96) 

H- 1 1 .  Congressional  Language  Affecting  Military  Personnel  Information  Management 
Programs  (5/96) 

•  NSIPS 

•  SIDPERS-3 
.  RCAS 

H-12.  Civilian  Personnel/Payroll  Private  Sector  Benchmarking  Survey  -  Final  Report  - 
(Executive  Summary)  (9/21/94) 

H-13.  Study  of  Options  for  the  Future  Management  of  the  Services:  Personnel 
Administration  and  Pay  Delivery  Systems  (Executive  Summary)  (12/1/95) 

H-14.  Acronym/Term  Listing  for  the  Defense  Science  Board  Task  Force  on  Military 
Personnel  Information  Management  (Rev.  7/29/96) 

H-15.  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE) 
Integration  and  Runtime  Specification  (I&RTS)  -  Preliminary  Report,  Version  2.0, 
(Executive  Summary)  (October  23, 1995) 

H-16.  Business  Process  Improvements  Summary  -  Military  Personnel  Information 
Management  Program  (Update:  2/8/96) 

H-1 7.  Annotated  Bibliography  of  Selected  Reports  for  Military  Personnel  Information 
Management  Program  (2/96) 
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APPENDIX  A:  EXHIBITS 


This  appendix  contains  the  documents  referenced  in  the  DSB  Task  Force  Final  Report. 

They  include: 

A-1 .  Acceleration  of  Design  and  Development  of  Common  Military  Personnel/Pay 
Management  Objective  System  -  Resources  Required  (revised  8/31/96) 

A-2.  Using  COTS  Software  In  Systems  Development  from  National  Research 
Council  of  Canada,  Institute  for  Information  Technology,  Software 
Engineering  Group  (Copyright  1996) 

A-3.  “Retool  Human  Resources”  and  “HR  App  Meets  Critical  Needs”  articles  from 
Datamation  Journal.  (6/15/95) 

A-4.  Defense  Science  Board  Military  Personnel  and  Pay  System  Task  Force 
Commercial  Off  The  Shelf  (COTS)  Feature  Comparison  Charts  (8/8/96) 

A-5.  Ms.  Padalino’s  memo  with  SYBASE  input  to  the  Defense  Science  Board  Task 
Force  on  Military  Personnel  Information  Management  Report  -  BAFO, 
(8/7/96) 

A-6.  Mr.  Selsor’s  memo  with  GRCI  input  to  the  Defense  Science  Board  Task  Force 
on  Military  Personnel  Information  Management  Report  -  BAFO,  (8/7/96) 
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QUESTION:  What  resources  would  be  required  to  complete  the  functional 
definition  and  software  development  of  an  objective  military  personnel/pay 
management  system  with  an  IOC  of 2001? 

This  outline  focuses  only  on  this  question.  It  does  not  address  other  critical  factors, 
such  as  programmatic  issues,  management  structure,  and  implementation.  The 
estimates  provided  below  are  based  on  two  staffing  alternatives  and  the  requirements 
definition  approach  currently  in  use  by  the  Joint  Working  Group.  Manpower  estimates 
are  only  for  definition  of  functional  requirements  and  do  not  include  personnel  attached 
to  the  Executive  Agents.* 

Background.  At  the  Defense  Science  Board  Task  Force  meeting  on  June  26, 
participants  agreed  that  it  should  be  both  functionally  and  technically  feasible  to  design 
and  develop  a  common  system  (that  would  accommodate  Service-specific  requirements) 
with  an  IOC  of  2001.  It  was  recognized  that  this  would  require  an  acceleration  of  the 
current  process  for  defining  requirements  and  developing  software.  P&R  was  asked  to 
provide  an  estimate  of  the  resources  required  to  complete  these  two  tasks.  It  was  also 
recognized  that  additional  factors  would  need  to  be  considered,  such  as  the  management 
structure,  funding  and  reporting  lines.  Service-specific  implementation  plans,  and  the 
extent  to  which  hardware  currently  being  purchased  by  the  Services  could  be  used  to 
deploy  the  objective  system. 

Assumptions.  The  requirements  defined  below  are  based  on  the  following  assumptions. 

1 .  Military  personnel  management  is  the  broad  functional  area  defined  by  the 
135  nodes  of  the  process  model  developed  by  the  Joint  Working  Group. 

2.  Resource-intensive  case  tools  will  continue  to  be  used  to  define  functional 
requirements. 

3.  The  Joint  Working  Group  experience  that  three  months  are  required  to 
complete  functional  definitions  for  each  node,  from  initiation  to  hand-off  to 
the  software  development  team. 

4.  The  Services  will  continue  to  be  the  primary  drivers  in  development  of 
requirements. 

5.  The  Executive  Agents  (USN  and  USAF)  for  the  prototype  effort  will 
continue  as  Executive  Agents  for  the  full  development. 

6.  The  accelerated  program  will  require  additional  personnel  for  2.5  years, 
beginning  in  October  of  1996,  after  which  a  permanent,  much  smaller  staff 
will  remain  in  place  for  continued  maintenance  and  updates. 

Timeline.  The  timeline  was  developed  working  backwards  from  an  IOC  date  of  2001. 
The  proposed  timeline  is  at  chart  1. 

Approach.  The  approach  builds  on  and  accelerates  the  work  of  the  Joint  Working 
Group  and  the  P&R  Information  Management  office. 

1.  Functional  requirements  will  be  incorporated  modularly,  with  precedents. 

2.  Requirements  will  be  analyzed  concurrently  rather  than  sequentially  and 
passed  to  developers  as  modules  are  completed. 
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Staffing  Alternatives.  Two  alternatives  are  presented  for  staffing  the  process  for 
defining  functional  requirements.  Both  alternatives  accelerate  the  current  process  from 
one  module  (or  node)  every  three  months  to  twelve  modules  every  three  months.  Both 
alternatives  assume  significant  contractor  support,  which  is  provided  through  the 
funding  lines,  and  both  alternatives  assume  continued  support  from  the  Information 
Management  (IM)  office  or  some  comparable  organization. 

•  Workshop  approach:  This  alternative  follows  the  pattern  that  the  Joint 
Working  Group  has  been  using  for  requirements  definition.  Subject  matter 
experts  are  brought  in  from  the  Services  for  two-week  intensive  workshops. 
Members  of  the  JWG  participate  in  each  workshop  to  ensure  continuity  and 
consistency.  JWG  members  also  complete  the  complex  processes  required 
to  complete  the  package  for  hand-off  to  the  Executive  Agents.  This  would 
require  that,  in  addition  to  the  part-time  subject  matter  experts,  the  full-time 
staff  would  have  to  grow  to  about  55  personnel  (including  the  IM  staff)  for 
the  duration  of  the  2.5-year  requirements  definition  period,  allowing  at  least 
two  JWG  members  to  participate  in  each  workshop  and  providing  adequate 
support  for  integration  and  management.* 

•  Team  approach:  This  alternative  creates  standing  teams  for  the  2.5-year 
period.  Each  team  would  focus  on  one  module  in  each  three-month  period. 
The  team  members  would  be  or  become  the  functional  experts  and  would 
obtain  or  provide  whatever  expertise  was  required.  This  alternative  would 
require  at  least  90  to  100  government  personnel  (military  and  civilian)  in 
addition  to  the  contractor  support. 

Funds.  Chart  2  estimates  funds  required  to  provide  contractor  support  to  complete  the 
definition  of  functional  requirements  and  to  complete  the  software  development  by  the 
Executive  Agents.  The  estimates  for  the  EA  funding  requirements  was  provided  by  the 
USN  and  USAF  Executive  Agents. 

Pros  and  Cons  for  each  Staffing  Alternative. 

Workshop  Approach: 

Pros:  Requires  fewer  full-time  personnel  assigned  from  Services. 

Ensure  maximum  participation  from  subject  matter  experts. 

Cons:  Provides  less  continuity  and  creates  new  learning  curves  with  each  node. 

Team  Approach: 

Pros:  Provides  continuity  and  maximizes  economies  of  scale. 

Cons:  Requires  more  full-time  personnel  assigned  from  Services. 

*  To  perform  life-cycle  management  and  coordination  activities  for  the  objective 
system,  additional  permanent  staff  of  five  will  be  required,  for  a  total  of  60  for  2 
1/2  years,  reduced  to  25  thereafter. 
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MILITARY  PERSONNEL  MANAGEMENT 

OBJECTIVE  SYSTEM 


Chart  1 
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Estimated  Program  Costs  $83,660 
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Using  COTS  Software  in  Systems  Development 


Using  "Commercial  Off-the-shelf  (COTS)  software  components  to  build  systems  has  been 
proposed  as  a  means  of  developing  software  with  reduced  risk  and  cost  while  increasing 
functionality  and  capability  of  the  system.  Building  a  system  based  on  COTS  components 
involves  buying  a  set  of  pre-existing,  proven  components,  building  extensions  to  satisfy  local 
requirements,  and  gluing  the  components  together.  The  advantages  claimed  are  that  the  COTS 
components  are  honed  in  the  competitive  marketplace  resulting  in  increased  capability, 
reliability,  and  functionality  for  the  end  user  over  what  would  be  available  from  custom  built 
components.  COTS  software  components  from  different  vendors  are  expected  to  be  integrated 
easily,  work  in  a  wide  range  of  environments,  and  support  extensions  and  tailoring  to  local 
requirements. 

The  reality  of  the  situation  is  quite  different.  Many  organizations  find  that  using  COTS  software 
carries  a  high  risk  and  expense  during  development,  during  deployment,  and  during  the  ongoing 
evolution  and  maintance  of  the  system.  Using  COTS  components,  systems  are  often  hard  to 
build,  to  support,  and  to  maintain.  The  problems  encountered  may  be  related  to  the  processes  an 
organization  uses  to  build  systems,  in  the  technologies  used  to  construct  the  system,  and  in 
the  way  systems  containing  COTS  components  evolve. 

The  Institute  for  Information  Technology  (ITT)  is  undertaking  a  research  project  to  understand 
the  problems  associated  with  COTS  software  based  development  from  the  perspective  of  an 
organization  that  is  trying  to  use  COTS  components  to  build  systems.  Given  that  developers  from 
different  organizations  are  going  to  continue  to  develop  software  that  does  not  glue  together 
easily,  that  may  not  evolve  according  to  the  users’  wishes,  that  is  continually  evolving  and 
changing,  and  that  may  not  be  properly  supported,  how  should  an  organization  go  about  using 
COTS  software  components  for  system  construction?  The  objective  of  this  research  is  to: 

•  Determine  qualitatively  the  advantages  and  disadvantages  of  using  COTS  software  in  the 
construction  of  systems. 

•  Identify  the  types  of  systems  that  can  benefit  from  the  use  of  COTS  components  and  the 
types  of  COTS  components  that  can  be  used  within  these  systems. 

•  Criteria  for  evaluating  COTS  software  components. 

•  Modify  existing  software  and  system  development  processes  in  order  to  maximizes  the 
effective  use  of  COTS  software. 

•  Investigate  technologies  and  architectures  that  enable  the  use  of  COTS  software. 

This  research  is  sponsored  by  the  Chief,  Research  and  Development  of  the  Department  of 
National  Defence . 
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1.  Introduction 

The  Software  Engineering  Group  of  the  National  Research  Council  (NRC)  is 
currently  undertaking  a  research  project  into  the  implications  of  using  off-the- 
shelf  (OTS)  software  to  build  long-lived  military  systems.  The  purpose  of  this 
project  is  to: 

•  Determine  qualitatively  the  advantages  and  disadvantages  of  using  OTS 
software  in  the  construction  of  systems. 

•  Identify  the  types  of  systems  that  can  benefit  from  the  use  of  OTS 
components  and  the  types  of  OTS  components  that  can  be  used  within 
these  systems. 

•  Develop  criteria  for  evaluating  OTS  components. 

•  Identify  problems  with  the  existing  software  and  system  development  and 
procurement  process  that  inhibit  the  effective  use  of  OTS  software. 

•  Investigate  technologies  and  architectures  that  enable  the  use  of  OTS 
software. 

This  paper  presents  some  initial  results  and  observations  regarding  the  OTS 
software  usage.  These  results  are  based  on  the  following  activities: 

•  A  series  of  interviews  was  conducted  with  personnel  within  DND  who  are 
involved  in  procuring  or  maintaining  systems  that  contain  off-the-shelf 
components. 

•  Round  table  discussions  and  interviews  with  researchers  and  commercial 
software  developers  who  are  interested  in  component  based  software. 

•  Review  of  the  literature  to  determine  the  current  state  of  the  practice  and 
current  state  of  the  research  in  building  systems  from  OTS  components, 
building  software  components,  and  open  standards  that  enable  the  use  of 
off-the-shelf  software. 

•  Experimentation  with  different  technologies  and  standards  that  are 
designed  to  enable  the  use  of  off-the-shelf  components. 

2.  Characteristics  of  off-the-shelf  based  system  development 

Building  systems  from  off-the-shelf  software  components  Is  an  Instance  of  a  type 
of  software  re-use.  It  differs  from  other  forms  of  re-use  in  that  the  system 
developer  buys  the  components  (usually  without  the  source)  from  third 
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developers  and  then  integrates  the  components  into  the  system.  Characteristics 
of  this  approach  to  system  development  include: 

•  A  component  software  product  is  designed  to  be  sold  in  many  copies  to 
multiple  customers  with  minimal  changes. 

•  Pre-existence  is  one  virtue  -  not  only  because  it  can  shorten  delivery 
schedules  but  because  it  means  the  customer  can  use  pilot  studies  to 
rethink  "requirements"  and  to  investigate  deployment  problems. 

•  Honing  in  the  marketplace,  especially  a  competitive  marketplace,  improves 
specification,  design,  and  implementation  in  ways  that  a  waterfall 
development  cannot  anticipate. 

•  Vendor  is  responsible  for  ongoing  support  and  maintenance  -  but  this 
implies  customer  must  accept  upgrades 

•  No  single  customer  has  control  over  specification,  schedule,  or  evolution. 

•  The  specialized  nature  of  the  OTS  product  allows  the  customer  indirect  use 
of  the  rare  skills  of  designers  and  implementers. 

•  Access  to  source  code  is  unusual. 

•  The  development  process  used  may  not  be  your  favorite  nor  appropriate 
for  easy  configuration  management  and  control. 

•  Internal  documentation  may  be  non-existent  or  not  accessible. 

•  Technical  information,  especially  as  to  limitations,  performance,  or  resource 
consumption,  may  never  have  been  collected. 

•  User  level  documentation,  customer  documentation,  and  training  may  be 
well  developed. 

•  Depending  on  the  source  of  the  components,  they  are  referred  to  as 
Commercial  off-the-shelf  (COTS),  Military  off-the-shelf  (MOTS), 
Government  off-the-  shelf  (GOTS),  etc. 

3.  Off-the-shelf  components:  state  of  the  art 

As  part  of  this  research  we  have  talked  to  numerous  military,  government, 
academic,  and  industrial  people  involved  in  the  development  of  COTS 
components,  or  building  systems  from  COTS  components,  and  sunreyed  the 
literature  to  identify  problems  other  organizations  had  had  when  building  systems 
from  COTS  components  [BR095,NAS95].  The  purpose  of  this  survey  was  to 
understand  the  current  practices  of  DND  in  terms  of  COTS  software,  determine 
the  experiences  and  attitude  of  those  responsible  for  software  systems,  and  to 
learn  what  kinds  of  problems  (and  solutions)  people  had  experienced  in  relation 
to  COTS  software  integration. 

Within  DND  we  surveyed  eleven  different  groups  or  organizations  and  eighteen 
different  individuals  involved  in  about  fifteen  projects.  The  projects  were  primarily 
Command  and  Control  systems  or  information  systems. 
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There  was  no  attempt  to  gather  quantitative  data.  Very  few  useful  metrics  were 
available  and  it  is  unlikely  that  these  would  have  any  relevance  across  different 
projects.  Thus  the  data  gathered  is  qualitative  and  anecdotal. 

3.1  Current  practices 

Within  DND  all  the  systems  looked  at  as  part  of  this  study  were  either 
Information  systems  or  command  and  control  systems.  We  did  not  look  at 
weapons  systems  but  are  aware  of  a  number  of  systems  that  use  OTS  software, 
particularly  where  it  is  embedded  within  specialized  OTS  hardware. 

There  are  different  ways  of  using  off-the-shelf  software.  The  primary  approaches 
we  found  within  DND  are  the  following: 

•  Buy  and  adapt.  The  buy-and-adapt  model  is  characterized  by  acquiring  a 
single  complete  working  system  that  satisfies  most  of  the  requirements  of 
the  acquisition  agency  and  adapting  and  extending  it  for  local  needs.  The 
adaptation  of  the  system  is  done  by  extending  it  through  add-ons, 
interfacing  with  other  applications,  or  modifying  the  off-the-shelf  application 
through  source  code  changes  (But  then  is  it  really  "off-the-shelf"? 

•  Component  integration.  The  component  integration  model  of  software 
development  builds  software  systems  by  integrating  a  number  of  off-the- 
shelf  components  where  each  component  satisfies  some  of  the 
requirements  of  the  system.  This  model  usually  depends  on  the  use  of 
some  “gluing  technology”,  which  may  be  unrelated  to  the  components,  to 
provide  an  interface  between  components. 

3. 1. 1  Buy-and-adapt  System 

The  buy-and-adapt  model  of  OTS  reuse  builds  systems  by  purchasing  an 
application  which  satisfies  most  of  the  system  requirements  and  then  extending 
and  tailoring  the  application  to  satisfy  local  requirements.  This  model  of 
development  was  used  for  both  command  and  control  and  information  systems. 
The  applications  bought  were  both  military  off-the-shelf  (MOTS)  and  commercial 
off-the-shelf  (COTS). 

Within  DND  we  observed  two  methods  for  modifying  and  extending  systems: 

•  •  API's.  Most  of  the  systems  which  were  bought  and  adapted  had  some 
kind  of  an  API.  The  developer  can  write  a  controlling  program  that  calls  the 
COTS  component  API  as  required.  Typically  this  involves  writing  a 
"wrapper"  around  the  OTS  component  to  isolate  the  workarounds  and 
extensions  and  provide  a  somewhat  higher  level  of  abstraction  to  the 
component's  interface.  The  developer  then  writes  the  main  program  that 
controls  the  sequence  of  execution  including  calls  to  the  OTS  component 
(Figure  la). 

•  Modifying  source.  If  an  OTS  system  does  not  satisfy  all  requirements  then 
the  supplier  (or  a  contractor  with  access  to  the  source  code)  can  modify  the 
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application  to  satisfy  the  local  requirements.  However,  once  modifications 
to  the  source  code  is  done  the  acquisition  agency  no  longer  has  an  off-the- 
shelf  component  but  rather  has  a  one-of-a-kind  system.  Using  this 
approach  there  is  a  risk  that  these  changes  will  become  orphaned  and  the 
vendor  will  not  support  them  during  the  normal  course  of  upgrading  the 
product. 

The  problems  we  have  seen  with  systems  that  have  been  bought  and  adapted 
are: 


•  Limited  source  of  supply.  One  argument  for  using  COTS  is  that  competition 
between  vendors  will  drive  prices  down  and  improve  quality  of  the  systems. 
For  many  MOTS  software  applications  there  is  limited  choice  of  systems  for 
purchase  with  minimal  ongoing  competition  and  these  arguments  do  not 
apply. 

•  New  releases  of  OTS  component.  Replacing  older  versions  of  COTS 
software  with  newer  releases  is  difficult.  New  requirements  or  new 
hardware  may  preclude  continued  usage  of  the  older  version.  Extensions 
and  modifications  made  to  the  previous  version  must  be  re-integrated  into 
the  newer  system.  We  saw  three  approaches  to  this  problem: 

•  Assume  (hope?)  the  API  and  data  formats  of  the  new  releases  will  not 
change  significantly. 

•  If  extensions  are  added  to  the  OTS  software,  have  the  vendor  certify  the 
changes  as  being  compatible  with  all  future  releases. 

•  If  modifications  have  been  made  to  the  original  source  code,  contract  with 
the  original  developer  (or  someone  with  access  rights  to  source)  to  make 
modifications  to  new  releases.  There  is  potentially  a  high  risk  (and  high 
expense)  associated  with  this  approach:  a  complete  process  of  analysis, 
development,  documentation,  and  testing  must  be  performed  for  the  one 
instance  of  the  product. 

Within  the  commercial  world  the  use  of  API's  and  source  code  modification  are 
used  but  there  is  also  a  large  amount  of  interest  In  using  a  concept  known  as 
frameworks .  A  framework  is  a  large  scale  component  or  an  application  which  is 
designed  to  be  extensible  and  integrated  with  other  frameworks.  With  a 
framework  one  is  not  buying  a  component  called  through  an  API,  but  rather  an 
Implemented  architecture  inside  of  which  one  can  embed  extensions  using 
techniques  such  as  plug-ins  and  inheritance.  The  difference  between  traditional 
API  based  components  and  frameworks  is  shown  graphically  in  Figure  1 .  In  the 
traditional  model  (Figure  1a)  the  custom  code  defines  the  architecture  and  the 
COTS  component  Is  embedded  in  and  called  by  the  custom  code;  in  frameworks 


A-2-10 


(Figure  1b),  localizations  and  extensions  are  embedded  inside  the  framework, 
use  the  frameworks  architecture,  and  are  called  by  the  framework. 


Figure  1. 

Ttaditianal  model:  COT8  embedded  inside  custom  cede. 

(b)  Cwtomoode  embedded  ineide  COT8. 

Frameworks  can  be  constructed  to  provide  generic  services  (such  as  the 
OpenDoc  framework  which  provides  an  open  architecture)  or  they  can  provide 
services  within  a  specialized  application  domain,  such  as  to  the  financial  services 
industry,  manufacturing,  health  services,  etc. 

A  framework  can  be  tailored  and  extended  In  a  number  of  ways: 

•  Plug-ins.  Developers  can  add  functionality  to  an  application  by  writing  a 
"plug-in".  A  plug-in  notifies  the  framework  of  its  capabilities  and  services 
and  the  framework  calls  the  plug-in  as  required.  Effectively  this  reverses 
the  traditional  role  of  a  component  and  the  custom  code:  rather  than  the 
custom  code  calling  the  component  through  an  API,  the  framework  calls 
the  custom  code  that  is  implemented  as  a  plug-in. 

•  Scripting.  A  script  Is  an  executable  fragment  of  code  which  Is  dynamically 
linked  to  components  of  the  system.  A  script  can  be  used  to  extend  the 
behaviour  of  a  component  (by  having  the  component  execute  the  script),  or 
it  can  be  used  as  a  coordination  mechanism  to  integrate  two  or  more 
components  (by  providing  the  "glue"  for  linking  the  components  together). 
Over  the  last  few  years,  numerous  languages  designed  specifically  as 
scripting  languages  have  been  developed  and  are  being  used  on  a 
commercial  basis  (e.g.,  ObjectREXX,  Visual  Basic,  AppleScript,  JavaScript, 
tcl,  Perl,  Python,  etc.)  Currently  there  are  two  rival  scripting  architectures 
which  are  competing  for  market  dominance:  the  Open  Scripting 
Architecture  (OSA)  which  is  supported  by  IBM,  Apple,  and  most  of  the 
computer  manufacturers;  and  OLE  Automation  which  is  supported  by 
Microsoft. 

•  Inheritance.  Inheritance  allows  specific  parts  within  a  component  to  be 
specialized  and  modified.  Current  object-oriented  standards  allow 
inheritance  to  be  used  by  developers  who  only  have  access  to  executable 
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binaries  and  not  to  the  source  code.  In  contrast  to  scripting,  which  is  often 
done  by  end-users  or  their  support  staff,  inheritance  requires  a  deep 
knowledge  of  the  architecture  of  the  framework  and  would  normally  be 
applied  only  be  professional  developers.  Examples  of  this  approach  can  be 
found  in  the  CORBA  object  model  and  DSOM  from  IBM. 

Within  the  commercial  world  building  systems  from  frameworks  can  be  viewed 
as  a  "just-in-time"  programming  model  where  components  move  along  an 
assembly  line  from  the  developer  through  the  integrator  to  the  end  user,  and 
functionality  is  added  at  the  latest  possible  point  along  this  line.  Component 
developers  build  large-scale  components  that  provide  services  that  appeal  to  a 
large  market;  integrators  extend  and  combine  the  components  to  build  systems; 
and  end  users  and  their  support  staff  tailor  the  system  for  local  needs. 

Although  frameworks  are  being  developed  (or  at  least  talked  about)  within  many 
commercial  application  domains  there  is  currently  limited  activity  in  the  military 
domain.  There  is  an  initiative  at  DoD's  ESC  Software  Center  (described  in 
[BR095])  which  is  being  developed  along  the  line  of  frameworks.  The  objective 
is  to  define  a  set  of  product  lines  each  with  its  own  evolving  architecture  and 
continuing  qualifying  COTS  products.  A  client  approaching  ESC  for  a  solution  will 
be  sold  one  of  these  standard  architectures  tailored  to  the  clients  needs.  By  this 
means  they  intend  to  have  the  capability  to  deliver  systems  to  their  clients  quickly 
and  with  very  little  development  effort.  The  price  they  pay  for  the  short  delivery 
time  and  low  cost  is  that  they  do  not  expect  to  be  able  to  satisfy  1 00%  of  their 
clients  requirements,  but  they  do  expect  to  satisfy  enough  of  the  requirements 
that  they  are  considered  a  cost  effective  solution. 

Another  example  of  a  framework  based  approach  is  the  DIGEST  GIS  system 
being  developed  at  DREV.  The  GIS  system  is  the  framework  to  which  plug-ins 
can  be  added  to  extend  functionality.  The  objective  is  for  development  of  both 
the  GIS  framework  and  the  plug-ins  to  be  taken  over  by  commercial  developers. 

3. 1. 2  Integrating  components 

The  integration  approach  to  COTS  usage  involves  the  developer  buying  two  or 
more  separate  COTS  software  packages  and  integrating  them  into  a  larger 
system. 

A  component  to  be  integrated  can  be  packaged  in  many  different  ways.  Within 
the  systems  we  studied  we  observed  the  following  component  types: 

•  Procedural  libraries.  Component  is  delivered  as  a  set  of  library  routines 
which  are  linked  in  at  build  time. 

•  Legacy  applications.  Application  is  part  of  an  organizations  structure  and 
workflow  and  must  be  included  as  a  component  within  the  new  system. 
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•  Off-the-shelf  applications.  Component  is  delivered  as  a  stand-alone 
application  (which  may  or  may  not  have  open  interfaces  and  data  formats.) 
Integration  can  take  different  forms,  such  as  API  calls,  shared  data  in 
standard  formats,  "screen-scraping",  event  passing,  drag-and-drop,  etc. 

The  most  common  form  of  integration  observed  was  the  use  of  shared 
databases  and  shared  files. 

•  Tools.  Tools  are  a  mechanism  to  automatically  build  source  code.  An 
example  is  a  GUI  builder.  Tools  typically  work  by  having  the  developer 
describe  the  system  using  the  tool's  language.  The  tool  then  generates 
source  code  that  can  be  compiled  and  linked  with  the  other  components  of 
the  system. 

•  System  services.  Operating  Systems,  databases,  windowing  systems,  and 
device  drivers  are  typically  purchased  today  as  COTS  components,  and 
perhaps  even  considered  part  of  the  hardware  platform  on  which  the 
system  is  to  be  built. 

In  addition  to  the  above  component  package  types,  there  are  others  ways  of 

packaging  components.  Two  of  interest  are  the  following: 

•  Frameworks  as  defined  in  the  previous  section. 

•  OLE  Components.  The  OLE  standard  from  Microsoft  promotes  a  number  of 
technologies  which  are  intended  to  enable  reusable  components.  These 
include  OLE  Custom  Components  (OCXs)  and  OLE  Automation  servers.  At 
DREV  there  was  a  project  being  undertaken  to  package  a  GIS  system  as  a 
set  of  OLE  component  which  can  be  extended  through  plug-ins  from 
commercial  developers. 

The  successful  uses  of  COTS  components  which  we  observed  within  DND  were 

the  following: 

•  GIS.  Numerous  GIS  libraries  exist  and  provide  adequate  functionality  for 
many  applications. 

•  GUI  builders.  GUI  builders  are  tools  which  are  becoming  mature  and 
indispensable. 

•  Office  automation  software.  Software  such  as  calendars,  word  processors, 
and  spreadsheets  are  used  within  many  systems.  The  interaction  between 
these  applications  and  other  components  of  the  system  were  done  primarily 
through  desktop  features  such  as  drag-and-drop  and  enclosing  files  within 
e-mail  messages. 

•  E-mail  and  messaging  systems. 

•  Databases.  Databases  are  an  accepted  part  of  many  systems  and  are 
almost  always  bought  off-the-shelf. 
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•  Operating  systems,  Including  low-level  software  such  as  device  drivers, 
windowing  systems,  etc. 

The  above  list  is  made  up  of  applications  and  components  which  are  mature  and 
pervasive  in  a  large  number  of  systems.  This  maturity  Is  a  likely  reason  why  they 
have  been  successfully  marketed  as  COTS  software  components. 

Outside  of  the  mature  areas  listed  above,  project  and  maintenance  managers 
were  generally  skeptical  about  the  feasibility  and  benefits  of  using  COTS 
components  to  construct  systems.  Applications  were  not  generally  designed  for 
intenworking  together,  the  applications  required  extensive  wrapping,  and  large 
amounts  of  functionality  needed  to  be  added  to  the  applications,  in  the  small 
number  of  examples  where  we  found  COTS  applications  outside  the  above 
domains  being  integrated,  the  attitude  of  the  managers  was  that  the  exercise 
could  not  be  considered  entirely  successful.  This  was  due  primarily  to  problems 
in  integrating  and  extending  the  functionality  of  stand-alone  applications  that 
were  not  designed  to  be  integrated. 

The  current  mechanisms  we  observed  for  Integrating  COTS  components  were 
the  following: 

•  Procedure  calls.  The  COTS  component  is  accessed  by  linking  to  a 
procedural  interface.  Examples  include  components  that  are  packaged  as  a 
procedural  library,  applications  with  an  API,  and  databases  with  an  SQL 
interface. 

•  Desktop  supported  capabilities.  Desktops  provide  limited  capabilities  for 
integrating  components  through  features  such  as  drag-and-drop, 
clipboards,  cut-and-paste,  etc.  This  is  generally  how  office  automation 
software  was  integrated. 

•  Data  sharing.  For  applications  that  store  data  In  a  standard  format 
integration  can  be  accomplished  by  having  components  read  and  write 
each  others  data.  The  shared  data  can  be  stored  in  shared  files  or  in  a 
shared  database. 

Problems  we  observed  with  the  integrating  COTS  components  include: 

•  Stability  and  support  from  suppliers  was  lacking. 

•  Integrating  new  releases  of  COTS  software  was  a  labour  intensive  and 
error-prone  task. 

•  Contractors  were  sometimes  unfamiliar  with  COTS  product. 

4.  Experiments  with  Open  Scripting  Architecture  (OSA) 

Traditionally,  commercial  software  packages  have  been  bought  and  used  on  an 
"as  is"  basis.  Commercial  applications  are  sold  as  executable  packages  that 
have  limited  functionality  for  adding  new  services  to  the  application.  Users  have 
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been  able  to  install  the  packages  and,  except  for  some  minor  tailoring,  have  had 
to  accept  the  existing  functionality  of  the  software  application. 

Recently,  there  has  been  an  initiative  to  open  up  software  applications  to  allow 
users  and  third  party  developers  to  extend  the  functionality  of  applications  and  to 
Integrate  applications  from  different  vendors  to  provide  more  sophisticated 
services  to  users.  This  trend  has  led  to  a  number  of  competing  and 
complementary  technologies  which  are  intended  to  allow  developers  to  package 
open  and  extensible  applications  which  can  be  enhanced  and  integrated  by 
users  and  third  parties. 

As  part  of  the  research  project,  we  are  experimenting  with  emerging  technologies 
that  enable  the  use  of  COTS  software  components.  One  set  of  experiments  we 
conducted  was  to  take  commercial  off-the-shelf  applications  and  to  extend  their 
capabilities  using  the  Open  Scripting  Architecture  (OSA).  The  purpose  of  this 
experiment  was  to  determine,  from  a  user's  perspective,  how  effective  the  OSA 
currently  is  for  extending  application  functionality. 

The  Open  Scripting  Architecture  (OSA)  is  one  of  the  two  scripting  architectures 
competing  within  the  marketplace  (the  other  being  OLE  automation).  OSA  is 
currently  under  control  of  the  CIL  consortium.  It  was  originally  developed  by 
Apple  Computer  and  is  an  integral  part  of  their  System  7.5  operating  system. 

OLE  automation  is  part  of  the  OLE  standard  from  Microsoft. 

OSA  has  been  adopted  as  the  scripting  standard  for  OpenDoc  and  thus  will  be 
available  on  most  platforms.  Currently,  OpenDoc,  including  OSA,  has  been 
released  for  Macintosh  System  7,  Windows,  and  OS/2.  The  architecture  is  not 
dependent  on  a  single  scripting  language.  Thus  on  the  Macintosh  platform,  OSA 
scripts  can  be  developed  in  AppleScript,  or  with  some  difficulty,  Usertalk  or  tcl. 
Under  OS/2,  OSA  scripts  can  be  developed  in  ObjectREXX. 

Scripting  architectures  are  designed  to  allow  developers  close  to  the  end  users 
(and  end  users  themselves)  to  Integrate  and  extend  applications.  They  are 
designed  primarily  for  integrating  and  tailoring  applications  rather  than  for  major 
development  work.  Applications  built  according  to  the  OSA  standard  can  extend 
their  behaviour  by  executing  scripts,  and  can  communicate  with  other  elements 
of  the  system  by  exchanging  events. 

Among  the  lessons  we  learned  from  these  experiments  are  the  following: 

•  Determining  behaviour  of  COTS  software  components  is  difficult. 

Documentation,  no  matter  how  well  done,  is  insufficient  for  understanding 
the  detailed  behaviour  of  components.  Other  than  reading  the 
documentation,  other  techniques  we  used  for  exploring  component 
behaviour  included: 
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•  Experimentation.  Understanding  the  characteristics  of  a  component 
always  required  experimentation.  The  OSA  provides  a  means  for 
CASE  tool  developers  to  build  environments  for  experimenting  with 
component  behaviour. 

•  Examples.  Most  of  the  COTS  components  we  integrated  had  a  large 
user  base.  Examples  and  workarounds  built  up  by  this  user  base 
were  invaluable  for  solving  many  problems  we  encountered.  This 
reflects  our  experience  with  many  popular  commercial  applications 
where  a  large  degree  of  support  for  the  application  comes  from  the 
user  base  rather  than  from  the  supplier. 

•  Browsers.  The  OSA  defines  a  means  by  which  applications  can 
advertise  their  objects,  data  structures,  etc.  Good  browsers  help  a 
developer  in  categorizing  and  locating  relevant  information  in  an 
applications  interface. 

•  Recordability.  OSA  defines  a  capability  whereby  events  can  be 
recorded  and  disassembled  into  an  appropriate  high-level  language. 
By  recording  an  applications  behaviour  and  studying  the  program 
fragment  generated  we  were  able  to  learn  about  the  characteristics 
of  some  applications. 

•  Extending  the  OSA  architecture  leads  to  conflicts  between  the  extensions. 
The  OSA  defines  a  means  of  adding  extensions  to  the  scripting  language. 
Many  of  these  extensions  are  being  developed  and  marketed  by  third 
parties.  Unfortunately,  with  the  large  number  of  extensions  being  developed 
naming  conflicts  are  arising  between  the  extensions. 

•  Performance  Is  low.  The  OSA  architecture  Is  currently  not  viable  for  time- 
critical  applications. 

•  Concurrency  is  not  supported. 

5.  Related  work 

There  are  a  number  of  initiatives  being  undertaken  by  different  organizations  on 
using  COTS  software  components.  This  section  lists  some  of  the  initiatives  which 
are  relevant. 

The  Software  Engineering  Institute  (SEI)  has  initiated  a  project  to  research  the 
implications  of  using  COTS  software  to  build  military  systems.  Their  research 
has  focused  on  two  Initiatives:  a  laboratory  project  to  investigate  the  integration 
of  COTS  CASE  tools  [ZAR94]:  and  a  two  day  workshop  on  the  use  of  COTS  in 
system  Integration  [BR095].  The  workshop  proceedings  are  particularly 
interesting  having  brought  together  industrial  and  military  people  to  talk  about 
COTS  integration  within  the  following  frameworks:  technical; 
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commercial/business:  system  architecture;  open  systems;  and  acquisition 
regulations.  The  workshop  identified  current  problems  and  future  directions  of 
research  In  COTS  integration. 

NASA  is  a  strong  advocate  COTS  software  and  has  a  number  of  workshops  and 
initiatives  in  this  area.  Their  main  focus  has  been  on  cost  and  risk  reduction 
through  reuse  of  software  components  across  different  projects.  Most  of  their 
published  data  has  focused  on  the  acquisition/development  process  needed  to 
foster  use  of  COTS  components.  They  identify  a  number  of  successful  examples 
of  COTS  component  usage.  In  addition  to  the  more  common  COTS  applications 
of  database  and  user  interface  tools,  they  provide  other  examples  such  as  a 
mission  that  integrates  three  different  COTS  applications:  telemetry  and 
command  processing,  orbit  prediction,  and  health  and  safety  monitoring 
[NAS95]. 

Among  the  lessons  they  have  learned  on  successful  usage  of  COTS  are  the 
following  [NAS95]: 

‘The  following  beliefs  about  COTS  packages  are  questionable 

•  COTS  package  solutions  are  less  risky 

•  I  can  buy  and  modify  a  COTS  package  more  quickly  than  I  can  develop  it 

•  There  is  a  COTS  package  for  my  application 

•  The  COTS  package  works  because  there  are  a  lot  of  copies  in  a  lot  of  other 
organizations 

•  The  vendor  will  keep  the  COTS  package  current. 

•  Vendor  literature  is  true. 

The  following  beliefs  are  reality: 

•  Vendors  over  commit  themselves 

•  Vendors  don't  supply  all  services 

•  The  software  may  not  meet  the  requirements. 

•  The  software  may  not  be  easily  modified. 

•  I  have  very  little  control  over  vendor  quality  and  schedule. 

•  My  organization  may  have  to  change  to  accommodate  this  COTS  package. 

•  Support  costs  for  modifications  may  be  20%  of  the  cost  of  the  modification  per 
year 

Some  fundamental  differences  between  COTS  based  development  and  custom 
development  are: 

•  COTS  based  development  may  need  infrastructure  earlier  to  demonstrate  and 
prove  the  COTS  package 

•  The  COTS  package  may  dictate  standards,  architecture,  and  design 

•  The  COTS  package  may  influence  work  flow 
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•  Picking  the  wrong  COTS  package  may  be  more  expensive  than  fixing  problems  in 
custom  software 

•  Issue  resolution  processes  need  to  be  in  place  earlier  to  resolve  COTS  package 
issues 

•  Issue  resolution  processes  may  be  more  complicated  because  of  the  addition  of 
the  vendor  and  possible  incompatibilities  between  the  vendor's  practices  and 
yours." 

A  number  of  new  standards  are  being  developed,  driven  primarily  by  commercial 
interests,  with  the  goal  of  making  component  based  software  development  a  reality.  The 
standards  of  interest  include: 

•  The  CORBA  standard  [OMG95]  from  OMG  (http://www.omg.org/).  The  OMG, 
through  CORBA,  is  standardizing  an  object-oriented  approach  to  re-usable 
components.  The  CORBA  standard  is  done  at  three  levels: 

•  CORBA  which  standardizes  how  component  interfaces  are  specified  and 
method  invocations. 

•  CORBA  services  which  standardizes  services  which  are  common  across 
many  applications.  Examples  of  services  include  security,  object  life  cycle, 
transaction  processing,  etc. 

•  CORBA  facilities  which  standardizes  frameworks  (i.e.,  reusable 
components)  within  a  specific  application  domain,  e.g.,  manufacturing, 
financial  services,  etc. 

The  CORBA  and  CORBAservices  have  been  standardized  by  the  OMG. 
CORBAfacilities  are  being  standardized  by  interest  groups  within  OMG  but  the 
standards  are  not  yet  in  place.  Although  CORBA  compliant  Object  Request 
Brokers  (ORBs)  are  available  commercially,  a  market  has  not  yet  developed  for 
components  built  to  this  standard. 

•  The  Component  Object  Model  (COM)  from  Microsoft.  This  provides  similar 
functionality  to  the  CORBA  standard  (but  not  CORBAservices  nor 
CORBAfacilities.)  The  COM  is  an  implemented  standard  to  which  components  are 
being  built.  It  is  limited  by  the  fact  that  in  its  current  form  it  does  not  support 
distribution  and  works  only  under  Microsoft  Windows. 

•  The  document  and  desktop  level  component  standards  of  OLE  (from  Microsoft) 
and  OpenDoc  (from  CIL).  OLE  and  OpenDoc  are  currently  implemented  on  a 
limited  number  of  platforms. 

6.  Issues  with  COTS  software  integration 

This  section  identifies  and  discusses  a  number  of  issues  related  to  building 
systems  from  COTS  components.  The  issues  discussed  are: 

•  Procurement/development  process 

•  Understanding  and  evaluating  components 

•  Evolution  of  software 

•  Architectural  issues  Role  of  standards 
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Embedded  systems 


6.1  Procurement/development  process 

A  number  of  participants  commented  that  one  of  the  key  elements  to  successful 
use  of  off-the-shelf  software  is  that  to  gain  the  benefits  while  minimizing  the  risk 
an  organization  must  be  willing  to  accept  the  software  component  as-is  with 
minimal  changes.  If  the  organization  is  not  willing  to  accept  the  capabilities  and 
limitations  of  the  software  as  they  exist  then  many  of  the  benefits  of  off-the-shelf 
software  will  not  be  realized.  This  conclusion  has  been  reached  not  only  by 
ourselves,  but  by  a  number  of  other  organizations  which  have  researched  the 
use  of  OTS  software.  The  Auditor  General  of  Canada  which  audited  a  number  of 
large-scale  government  systems  development  projects  made  the  following 
comment  while  auditing  a  Transport  Canada  system  that  is  heavily  dependent  on 
COTS  software: 

"While  the  acquisition  and  installation  of  a  commercially  available  software 
package  should  have  been  the  least  complex  of  the  systems  reviewed, 
the  extensive  modification  of  the  software ...  significantly  increased  the 
project  complexity.  As  well  as  adding  complexity,  such  modification  may 
make  the  implementation  of  new  releases  of  the  software  more  difficult 
and  costly....  A  significant  portion  of  the  savings  come  from  limiting  the 
extent  of  changes  to  the  commercial  software  package."  [AUD95] 

Therefore,  in  order  to  realize  the  benefits  of  COTS  software  a  procurement 
process  must  be  in  place  that  defines  requirements  according  to  what  is 
available  in  the  marketplace,  and  that  is  flexible  enough  to  accept  COTS 
solutions  when  they  are  proposed. 

The  issue  of  impediments  to  using  OTS  software  in  military/government 
procurements  is  addressed  by  NASA  [NAS95]  and  widely  discussed  in  the  SEI 
workshop  [BR095].Both  organizations  have  emphasized  the  need  to  accept  the 
capabilities  and  limitations  of  OTS  software  and  to  adapt  operational 
requirements  to  the  availability  of  the  COTS  components.  Currently,  rather  than 
approaching  procurement  with  the  attitude  "what  exists  off-the-shelf  and  how  can 
I  use  it",  the  procurement  process  identifies  strict  requirements  which  either 
excludes  the  use  of  COTS  components,  or  requires  large  modifications  to  COTS 
packages  in  order  to  satisfy  the  requirements. 

"In  the  old  process,  system  requirements  drove  capabilities.  In  the  new 
process,  capabilities  will  drive  system  requirements... it  is  not  a 
requirement  if  you  can't  afford  it"i 

A  number  of  the  procurement  issues  brought  up  by  SEI  workshop  include: 

•  Overly  specific  requirements  often  preclude  the  use  of  COTS  components. 

•  Use  of  MIL-SPECs  preclude  the  use  of  COTS. 
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•  Different  development  standards  are  needed  for  development  based  on 
COTS  software. 

•  Allow  contractors  to  submit  alternative  proposals  which  may  violate  some 
stipulations  of  the  solicitation  but  may  be  technically  superior  due  to  the  use 
of  COTS. 

New  military  standards  and  procedures  [MIL498]  recognize  the  need  for 
developers  to  include  consideration  of  COTS  components  during  the 
development  process.  Paragraph  4.2.3  and  Appendix  B  of  the  498  standard 
provide  specific  guidelines  for  incorporating  ‘reusable  software  products’  into 
software  systems.  These  guidelines  make  it  clear  that  unmodified  COTS  must  be 
handled  differently  than  modified  COTS.  In  general,  the  standard  requires  that 
modified  COTS  be  treated  as  if  it  were  normal  developmental  software.  This 
means  that  it  must  be  fully  documented  and  tested  within  the  scope  of  the  new 
system.  Much  of  the  standalone  testing  and  documentation  requirements  have 
been  eliminated  for  unmodified  COTS.  In  this  case  the  standard  provides  for  the 
use  of  existing  documentation  and  a  proven  performance  record  as  verification 
of  the  COTS  software. 

6.2  Understanding  and  evaluating  components 

A  component  which  is  worth  buying  is  likely  a  complex  piece  of  software.  In  order 
to  use  such  a  component  effectively  it  is  necessary  to  understand  it  at  quite  a 
deep  level.  Understanding  the  behaviour  of  complex  components  is  an  extremely 
difficult  task  for  a  number  of  reasons: 

•  The  documentation  is  incomplete  or  wrong.  Even  if  the  OTS  supplier  is 
conscientious  about  documentation,  a  complex  piece  of  software  will  not  be 
fully  and  correctly  documented.  Even  incomplete  documentation  may  be  so 
massive  as  to  be  incomprehensible  to  any  but  the  most  experienced  users. 

•  The  interface  may  be  very  complex.  Many  of  the  standard  components 
being  marketed  (e.g.,  OLE,  DCE)  have  APIs  with  hundreds  of  calls.  Not 
even  the  people  working  on  these  systems  know  how  each  API  call 
behaves  or  the  effect  of  particular  sequences  of  calls. 

•  There  are  bugs  in  the  software. 

There  is  no  easy  solution  to  understanding  complex  systems.  Documentation 
must  be  available  and  used,  but  a  deep  understanding  can  only  be  gained 
through  extensive  experimentation.  Trying  to  understand  these  components  has 
been  called  "an  experimental  science  without  any  laws  of  physics."  One 
advantage  of  using  a  COTS  application  with  a  large  user  base  is  that  much  of 
the  experimentation  has  been  carried  out  and  the  knowledge  is  available  in  the 
user  community. 
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Many  of  the  problems  encountered  with  integrating  COTS  components  cannot 
be  determined  before  integration  begins.  The  problems  are  of  such  a  nature  that 
they  only  appear  well  into  the  integration  process  [GAR95].  This  makes 
estimation  of  schedules  and  resource  requirements  extremely  difficult  where 
COTS  components  are  used.  Extensive  evaluation  of  the  COTS  component  will 
be  required  to  ensure  not  only  that  the  component  has  the  functionality  to 
perform  the  required  tasks  within  the  system,  but  also  that  the  additional 
functionality  inherent  within  the  component  does  not  interfere  with  the  system. 
The  cost  estimates  must  take  this  evaluation  process  into  account. 

6.3  Evolution  of  software 

Systems  are  constantly  changing;  COTS  components  within  systems  are 
constantly  changing.  This  evolution  of  systems  and  their  components  has  an 
impact  in  a  number  of  ways  on  the  maintenance  of  systems. 

All  people  we  interviewed  stated  that  there  was  a  large  amount  of  work  required 
to  integrate  new  releases  of  COTS  software  into  their  systems.  For  a  system 
constructed  from  multiple  COTS  components,  with  each  component  having  its 
own  release  schedule,  the  cost  of  integrating  each  new  release  of  each 
component  becomes  prohibitive. 

The  difficulties  arise  for  two  reasons: 

•  In  the  new  release  of  the  COTS  component  there  will  likely  be  changes  in 
the  behaviour,  interface,  assumptions,  performance,  bug  fixes  etc. 

•  Specializations,  extensions,  and  workarounds  made  to  the  older  version  of 
the  COTS  component  which  must  be  integrated  into  the  new  component. 
There  is  no  concept  of  "compliance"  as  in  mechanical  systems  where  parts 
are  not  defined  to  fit  exactly  but  rather  within  certain  tolerances. 

One  approach  to  the  problem  of  evolution  is  to  assume  that  the  system  (or  at 
least  the  OTS  component  within  the  system)  will  never  be  updated.  This  will  not 
be  practical  in  all  cases.  The  software  may  be  dependent  on  a  particular  platform 
that  is  no  longer  available  or  is  being  updated;  operational  requirements  may 
change;  or  bug  fixes  in  the  new  releases  may  be  required. 

Integrating  a  new  release  of  COTS  software  requires  a  significant  development 
effort.  First,  the  new  release  of  the  COTS  software  must  be  evaluated  to 
determine  what  has  changed  from  the  previous  release.  Second,  the  new 
component  must  be  integrated  into  the  system.  This  may  involve  adding  or 
removing  workarounds,  adding  new  extensions  to  take  account  of  new 
behaviour,  updating  documentation  and  training  procedures,  etc.  Finally,  the 
system  must  be  tested  and  verified. 
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6.4  Architectural  issues 

An  appropriate  software  architecture  addresses  three  issues  related  to  the  use  of 
COTS  software  components: 

•  Plug-and-play  of  components.  An  architecture  should  allow  pre-built 
components  to  be  quickly  assembled  into  larger  systems.  Components 
should  be  replaceable  with  a  minimum  amount  of  effort. 

•  Sharing  of  components/knowledge  across  projects.  Within  DND,  many 
projects  are  implemented  using  a  "stovepipe"  model  where  each  project 
develops  components  through  all  layers  of  the  system  with  very  little  re-use 
or  sharing  with  other  projects.  Many  projects  within  DND  have  similar 
functionality  and  requirements;  an  appropriate  architecture  would 
encourage  sharing  of  components  across  projects  to  take  advantage  of  this 
shared  functionality. 

•  Building  systems  as  components  for  larger  systems.  All  systems  built 
should  assume  that  one  day  they  will  be  the  off-the-shelf  component  which 
will  be  integrated  into  a  larger  system.  Systems  currently  being  built  within 
DND  have  limited  capability  to  be  integrated  Into  other  systems.  While  this 
is  a  highly  desirable  trait,  It  Is  obvious  that  commercial  vendors  will  be 
reluctant  to  add  increased  complexity  to  their  product  (at  increased 
development  cost)  to  provide  interworking  with  other  systems  unless  it  can 
be  shown  that  there  will  be  a  return  on  investment.  If  we  assume  that  DND 
cannot  effectively  influence  commercial  vendors,  then  the  viewpoint  should 
shift  to  ensuring  that  the  COTS  “glue”  is  flexible  enough  to  accommodate 
integration  with  future  systems. 

6.5  Role  of  standards 

There  is  clearly  a  role  for  standards  In  enabling  the  use  of  COTS  software  for 
building  systems.  If  standards  are  defined  correctly  and  if  software  developers 
build  components  which  comply  with  the  standards  then  this  goes  a  long  way 
towards  making  open  systems  a  reality.  There  are  already  a  large  number  of 
standards  which  have  had  an  impact  in  building  plug  compatible  software 
components.  Examples  of  these  Include  tcp/ip,  Xwindows,  and  SQL.  There  are 
many  other  standards  In  many  other  domains  that  have  the  potential  to  have  a 
similar  impact.  Some  of  these  address  directly  the  issue  of  Interoperable 
components  (e.g.,  OLE,  CORBA,  ODP,  OpenDoc,  etc.)  while  others  are  targeted 
at  a  specific  functional  domain. 

Although  standards  are  important  it  must  be  recognized  that  there  are  many 
problems  that  standards  do  not  address.  For  example,  regardless  of  how 
pervasive  standards  become,  they  do  not  in  any  way  eliminate  the  need  for 
evaluating  and  experimenting  with  COTS  components  or  solve  the  problems 
associated  with  maintenance  and  evolution  of  systems  containing  COTS 
components. 
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Another  issue  that  must  be  recognized  by  DND  is  that  to  gain  the  benefits  of 
standards  it  must  be  willing  to  accept  the  de  facto  standards  which  have  gained 
acceptance  in  the  marketplace.  DND  does  not  have  the  market  force  to  dictate 
standards  and  attempts  to  mandate  standards  will  likely  lead  to  the  use  of 
software  that  is  not  widely  supported  in  the  commercial  world.  The  role  of  DND 
should  be  to  monitor  and  understand  the  standards,  and  possibly  to  try  and 
influence  the  standards  definition  process,  but  once  a  standard  has  been 
accepted  in  the  commercial  world,  be  it  a  de  jure  or  a  de  facto  standard,  this 
standard  must  be  accepted  as  is  by  DND. 

6.6  Embedded  systems 

Although  using  COTS  components  is  usually  associated  with  information 
systems  there  are  instances  where  COTS  components  can  be  effectively  applied 
to  real-time  and  embedded  systems.  There  are  many  examples  of  real-time 
systems  which  make  some  use  of  COTS  components.  At  the  SEI  workshop,  the 
claim  was  made  that  the  Boeing  777  has  4  million  lines  of  COTS  software 
Including  Microsoft  products.  (It  was  also  claimed  that  to  Bill  Gates,  Boeing  was 
too  small  a  customer  to  meet  with.ja 

Areas  where  COTS  software  components  do  have  impact  on  embedded  systems 
include  the  following: 

•  Embedded  software.  When  buying  a  specialized  piece  of  COTS  hardware 
there  will  almost  always  be  software  embedded  in  the  equipment. 

•  Specialized  expertise.  If  embedded  systems  require  access  to  highly 
specialized  expertise,  this  expertise  may  be  more  readily  provided  by 
COTS  software  rather  then  attempting  to  hire  the  appropriate  experts. 

•  Operating  systems,  etc.  Embedded  systems  will  generally  use  commercial 
operating  systems. 

•  Standard  non-critical  components.  Many  embedded  systems  will  continue 
to  contain  standard  components  that  can  be  bought  off-the-shelf  and 
integrated.  These  include  for  example  report  generators,  GUIs,  databases, 
etc. 

issues  to  be  resolved  include: 

•  Certifying  components  that  are  critical.  If  a  COTS  component  is  to  be 
embedded  in  a  critical  system,  a  rigorous  certification  process  must  be 
performed  on  the  component. 

•  Constructing  firewalls  between  the  critical  system  and  uncertified  COTS 
components. 

'  2 Stated  by  Claude  M.  Del  Fosse,  SPC,  in  [BR095] 
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7.  Future  research 

Possible  future  directions  of  research  relating  to  COTS  software  integration 
Include  the  following: 

•  Develop  techniques  for  evaluating  and  experimenting  with  COTS 
components.  Select  a  number  of  products  and  attempt  to  define  or  develop 
tools  which  could  be  applied  to  a  COTS  component  to  pre-determine  the 
overall  functionality  of  the  component.  This  may  lead  to  the  definition  of  a 
classification  system  which  would  allow  project  groups  to  quickly  create 
short-lists  of  appropriate  software  components  for  their  particular  system. 
Another  approach  could  be  to  attempt  to  analyze  and  establish  evaluation 
criteria  to  be  used  to  determine  the  suitability  of  a  COTS  component  within 
the  framework  of  a  specific  system. 

Define  and  evaluate  technologies  and  architectures  that  promote  reuse  across 
projects  and  allow  applications  to  be  integrated  into  larger  systems.  Issues  which 
could  be  investigated  include: 

•  Coordination  languages  designed  specifically  for  integrating  and  extending 
COTS  applications, 

•  Component  architectures,  including  scripting  architectures  and  frameworks. 

•  Architectures  which  facilitate  component  reuse  across  projects. 

•  Experimentation  and  monitoring  of  standards  (CORBA,  OLE,  etc. ...). 
Experimentation  is  required  to  fully  understand  the  functionality  of  these 
standards  and  determine  how  they  may  (or  may  not)  facilitate  the  use  of 
COTS  software. 

Develop  a  guidebook  for  project  and  maintenance  managers  that  identifies 
issues  associated  with  COTS  development.  Contents  of  the  guidebook  could 
include: 

•  Overview  of  development  process  applicable  when  integrating  COTS 
components. 

•  Costs,  benefits,  and  risks  associated  with  COTS  software  reuse. 

•  Lessons  learned  from  previous  experiences  with  COTS  components. 

•  Tools  and  techniques  for  integrating  components. 
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•  Pick  an  application  domain  within  DND  and  determine  how  current  state-of- 
the-  art  commercial  software  satisfies  the  needs  of  DND  and  how  DND 
might  change  its  systems  to  take  advantage  of  COTS  within  this  domain. 
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RETOOL  HUMAN  RESOURCES 


You  bet  payroll  counts.  Back-office  human  resource  processing,  too.  But  the  real  reason 
to  go  to  a  client/server  HRMS  system  is  to  give  line  managers  the  power  they  need. 

By  Lee  The 

In  lots  of  companies,  "People  are  often  treated  worse  than  the  equipment,"  says  Bob 
Snelling  Jr.,  senior  VP  of  IS  at  Snelling  International,  a  temp  employment  placement 
agency  in  Dallas.  "They  deserve  to  be  treated  with  more  respect."  A  good  client/server 
HRMS  suite  can  help  companies  do  this.  Too  touchy-feely  a  reason?  No.  It  makes  good 
business  sense— and  it's  the  right  thing  to  do.  The  most  concrete  way  to  show  respect  isn’t 
commemorating  birthdays  in  the  company  newsletter  but  by  letting  people  manage  their 
own  resources.  Client/server  HR  systems  could  allow  employees  to  get  information  about 
benefits  or  change  personal  data  (new  address,  marital  status,  withholding,  and  the  like). 
Managers  can  use  those  systems  to  do  employee  reviews  or  initiate  hiring  and  disciplinary 
processes  (all  automatically  routed  to  the  right  sign-offs).  In  short,  client/server  HRMSs 
can  distribute  human  resource  functions  out  to  the  line  managers  and  to  individual 
employees.  And,  just  in  case  you  hadn’t  noticed,  enterprises  are  getting  squished.  The 
winds  of  change  have  blown  away  layers  of  the  hierarchy  that  used  to  provide  the  rungs 
on  a  career  ladder.  Employee  evaluation,  compensation,  and  career-planning  issues  have 
gotten  much  more  complex  and  need  to  be  administered  much  closer  to  the  involved 
employees.  All  this  doesn't  just  encourage  client/server  HRMS.  It  mandates  it. 

RETOOL  HR  AND  THE  COMPANY 

Jim  Holincheck,  a  Chicago-based  manager  in  Andersen  Consulting’s  software  intelligence 
group,  says  many  of  his  clients  are  using  HR  systems  to  retool  their  workforce  and  shift  to 
performance  management.  That  shift  includes  everything  from  building  appropriate  skills 
in  the  workforce  to  compensating  appropriately  in  the  market. 

You'll  need  to  be  able  to  tie  into  your  skills  database  to  see  what  has  been  planned  and 
completed.  This  is  one  place  where  workflow  comes  in.  Dun  &  Bradstreet  has  built 
proprietary  workflow  functionality  into  all  of  its  products,  including  human  resources. 
D&B  is  the  clear  leader  here.  Its  HR  Stream  is  fully  integrated  with  D&B  apps,  so  it 
sends  around  the  actual  transaction  or  piece  of  work,  not  just  a  message  or  form.  SAP  and 
Ramco  say  they  will  offer  equally  embedded  workflow  starting  late  this  year.  Also  check 
out  Edify.  A  number  of  vendors  use  Edify's  workflow  automation  products  in  conjunction 
with  Lotus  Notes  to  help  define  workflows  for  certain  processes. 

Tied  to  workflow  is  the  fact  that  enterprise  solutions  are  about  providing  the  right 
information  to  the  right  people,  regardless  of  departmental  boundaries.  Therefore,  your 
HR  system  needs  to  be  able  to  work  across  boundaries.  Dowdy  image  notwithstanding, 
HR  has  been  at  the  forefront  of  a  lot  of  avant-garde  technology,  including 
scanning,  imaging,  information  kiosks,  and  voice  response.  "We're  seeing  a  lot  of 
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innovation  in  HR  because  it  can  help  flow  to  the  top  line,"  Holincheck  says.  Clerical 
pencil  pushing  is  being  replaced  by  table-driven  packages  tightly  integrated  with  payroll. 
"So,  when  changes  are  made  to  benefits  elections,  the  payrolls  are  automatically  adjusted. 
"  Bottom  Line  THINK  LOOOOOOONG  TERM 

The  HR  system  you  buy  needs  to  be  more  than  client/server.  It  needs  to  be  far  more  than 
an  automated  back-office  HR  clerk  and  paymaster.  It  must  be  able  to  reflect  any  and  all 
organizational  changes  that  your  company  may  go  through  over  the  next  decade.  It  needs 
an  open  architecture  so  you  can  incorporate  voice  response,  telephony,  and  other 
new  hardware/software  technologies  as  needed.  And  the  vendor  needs  to  show  a  high 
level  of  consciousness  about  such  trends. 

Look  for  the  ability  to  extend  applications  without  disturbing  the  core  functionality,  and 
then  couple  that  with  sophisticated  upgrade  management.  You  need  to  be  able  to  locate 
processing  at  the  most  logical  place  relative  to  performance  and  security.  Object-oriented 
architecture  best  supports  this,  though  few  products  are  coded  this  way  yet.  Traditional 
HR/payroll  packages  are  long  on  record  keeping  and  short  on  reporting,  so  strong  query 
and  reporting  tools  are  a  must.  And  note  whether  those  reports  and  queries  can  go  against 
the  operational  data  without  needing  a  warehouse.  You  may  see  your  HR  department 
getting  distributed;  regional  people  may  handle  local  data  entry,  recruitment  support,  and 
other  tasks  while  headquarters  does  payroll  and  pension  administration.  Make  sure  your 
HRMS  supports  such  application  distribution. 

One  zone  of  contention  common  to  all  client/server  products  is  database  support.  Vendors 
like  D«&B,  Humanic  Design,  and  Oracle  currently  support  just  one  database.  Oracle 
HRMS  (not  surprisingly)  only  supports  Oracle.  The  same  is  true  for  Humanic  Design's 
Empire/SQL.  D&B's  HR  Stream  only  supports  Sybase.  Others,  like  PeopleSoft  HRMS, 
support  several  databases  but  forgo  stored  procedures  and  triggers  and  other  deep-level 
implementations.  This  is  a  tough  call,  with  advantages  both  ways.  D&B  is  working  on 
adding  Oracle  support,  but  it  seems  to  be  taking  forever  to  do  the  port.  Integral  claims 
that  its  ground-up  HR  line  rewrite,  due  this  fall,  supports  Informix,  Oracle,  Sybase,  stored 
procedures,  triggers,  and  all.  Deep  database  support  is  most  necessaiy  for  OLTP,  so  even 
if  you  lean  that  way  in  other  areas  it's  probably  not  as  crucial  with  HR.  Ramco,  which 
calls  itself  a  Microsoft  shop,  does  its  database  access  through  ODBC.  Holincheck  has  this 
tip:  Payroll  is  the  most  likely  bottleneck.  If  you're  unsure  whether  or  not  payroll  will 
fit  within  your  batch  window,  give  the  vendor  60  days  to  benchmark  payroll  in  house 
before  you  sign  on  the  dotted  line. 

Frequent  on-line  operations  do  loom  large  in  HR's  future,  starting  with  on-line  time  entry 
for  employees.  This  can  be  sent  by  e-mail  or  modem  to  a  central-processing  operation, 
with  links  to  attendance-monitoring  and  perhaps  more  general  project  management  and 
labor  allocation  modules.  There  could  be  automatic  feeds  into  payroll  and  even  the 
general  ledger.  That  way,  the  financials  can  use  the  hours  reported,  multiplied  by  standard 
rates,  to  get  a  cut  at  costs  right  away.  Then  they  get  trued  up  to  payroll  later. 
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Customizability  is  going  to  be  key  now  and  in  the  future.  The  trouble  is,  some  vendors 
rely  on  proprietary  toolsets.  SAP's  ABAP  4GL  is  more  arcane  than  PeopleSoft's 
PeopleTools.  D&B,  Humanic  Design,  and  Oracle  use  general-purpose  development  tools, 
which  your  shop  may  know  already.  But  don't  let  that  keep  you  from  looking 
at  PeopleTools  to  see  what  application-specific  functionality  can  do  for  you.  Whoever 
makes  the  tools,  make  sure  the  vendor  shares  your  goals.  If  you  want  to  implement 
workflow  and  the  vendor  doesn't,  you  may  be  out  of  luck.  Also,  vendor  perceptions  of 
how  much  you'll  need  to  use  a  toolset  vary.  Oracle  claims  to  deliver  90%  complete  HR 
apps,  whereas  PeopleSoft  expects  you  to  customize  a  lot  more. 

One  good  way  to  determine  which  products  fit  your  needs-or  how  much  customizing 
you'll  need  to  do  to  make  them  fit-is  to  put  them  through  a  specific  business  scenario. 

One  scenario  Andersen's  Holincheck  has  used  starts  with  identifying  an  open  position. 
Next,  you  search  for  internal  and  external  candidates  on  file,  place  an  ad  in  a  number 
of  newspapers,  capture  the  cost,  and  tie  it  back  to  the  requisition.  Then,  you  scan  in 
r,sum,s  sent  in  response,  and  OCR  them.  You  schedule  interviews,  record  results, 
automatically  generate  an  offer  letter,  scan  in  the  acceptance  letter,  then  at  the  point  of 
hire  transfer  all  germane  data  to  the  employee  record.  This  is  a  common  process.  The 
trick  is  to  see  how  well  it  works  and  how  easily  it  flows  from  one  stage  to  the  next. 

Long-time  HR  software  vendors  haven't  all  embraced  the  move  out  of  that  cozy  little  HR 
office,  so  a  mainframe  HR  background  is  no  guarantee  that  the  vendor  knows  what's 
happening  today.  Likewise,  some  financials  vendors  have  added  HR  products  mainly  to 
round  out  their  product  lines.  In  that  case,  you'd  better  find  out  just  how  well  the 
vendor  supports  its  HR  line,  from  dedicated  developers  to  in-house  consultants. 

Look  closely  at  how  much  integration  you  really  need  between  HR/payroll  and  financials. 
Being  able  to  get  it  all  from  one  vendor  offers  obvious  advantages,  but  they're  not  as  great 
as  they  might  be  from  integrating  other  areas  of  the  business. 

PARTS  AND  PROMISES 

Just  a  year  ago,  it  would  have  been  simple  to  talk  about  client/server  integrated  human 
resource  products  for  the  enterprise.  PeopleSoft  was  shipping  a  full  suite.  Everyone  else 
had  parts  and  promises.  The  vendors  that  have  done  the  best  job  of  playing  catch-up 
include  Cyborg,  Dun  &  Bradstreet,  Genesys,  Integral,  Lawson  Software,  Ross 
Systems,  Personal  Data  Systems,  and  Software  2000.  D&B,  Lawson,  and  Ross  are  best 
known  as  financials  vendors.  The  others  have  been  in  the  HR  business  for  years,  but  not 
all  of  them  have  completed  their  client/server  lines  yet.  Integral  is  missing  a  payroll 
module,  and  D&B  is  missing  both  payroll  and  benefits.  JD  Edwards  has  spent  the  last  two 
years  rewriting  its  in-house  CASE  tool,  and  the  first  products  will  ship  later  this  year. 

As  the  saying  goes,  "There's  many  a  slip  'twixt  the  cup  and  the  lip."  That  certainly  applies 
to  the  challenge  of  converting  from  legacy  to  client/server  apps,  because  there's  often  a 
world  of  difference  between  what  some  vendors  say  is  possible  and  what  really  is 
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possible.  D&B,  for  example,  provides  a  product  that  does  the  actual  data  conversion  and 
claims  it  reduces  conversion  time  by  70%.  D&B  also  has  a  coexistence  strategy  so  you 
can,  say,  run  legacy  payroll  on  the  mainframe  and  tie  it  in  with  client/server  HR.  ADP 
even  lets  you  tie  its  C/S  HRMS  to  either  a  service  bureau  payroll  system  or  an  in-house 
one.  And  JD  Edwards'  new  product  line  (code  named  "One  World")  will  let  you  start 
out  host-centric  on  your  current  hardware  and  operating  system,  then  move  to  full 
distributed  client/server  processing  incrementally. 

Illustration  by  Daniel  Pelavin 
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HR  APP  MEETS  CRITICAL  NEEDS 


When  Snelling  International  went  looking  for  a  client/server  HUMS  package,  it 
asked  vendors  to  jump  through  a  flaming  hoop  so  hot  only  one  package  could  handle  it. 

By  Lee  The 


Snelling  International's  mission-critical  application  is-no  fooling-its  human  resource 
management  system.  That's  because  Si's  core  business  is  hiring  and  deploying  a  huge, 
constantly  shifting  workforce  of  temp  workers.  Few  companies  wring  out  their  HRMS 
software  like  SI  does.  Yet  despite  having  needs  specific  to  the  employment  agency 
business,  SI  discovered  that  its  ideal  HR  package  didn't  come  from  the  vertical  market 
software  providers.  To  get  what  it  needed,  SI  had  to  turn  to  a  broad-spectrum  HR 
package. 

To  be  fair,  vertical  HR  packages  for  employment  agencies  are  designed  for  companies 
that  are  smaller  than  SI.  From  its  Dallas  headquarters,  SI  operates  through  251  franchise 
and  company-owned  offices  spread  across  five  countries.  Last  year,  it  processed  over 
50,000  W-2s  and  338,000  paychecks,  and  sent  reports  to  about  a  thousand  local,  state, 
and  national  regulatory  agencies. 

Si's  HRMS  needs  go  way  beyond  the  back-office  complexities  of  administering  a 
kaleidoscope  of  rotating  jobs,  employers,  locations,  industries,  government  regulations, 
and  people.  The  boom  in  downsizing  has  spawned  a  concomitant  boom  in  the  demand  for 
temporary  and  contract  workers.  Even  when  companies  are  looking  for 
permanent  employees,  they  are  turning  to  "try  before  you  buy"  contracts,  which  let 
employers  hire  SI  temps  after  13  weeks. 

Demand  has  outstripped  supply.  Thirty-thousand-odd  placement  agencies  (several  dozen 
of  which  operate  on  Si's  sc^e)  fight  over  good  temp  workers  of  every  stripe.  SI  has  been 
growing  30%  a  year,  rising  to  $300  million  in  revenue  last  year,  but  to  maintain  that 
growth  in  the  face  of  such  fierce  competition,  SI  needs  to  take  care  of  its  workforce 
and  manage  its  local  agencies  well.  SI  has  no  choice  but  to  deliver  superior  HR 
management. 
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Snelling  International's  IS  Report  Card 


D&B 

Oracle 

PeopleSoft 

Ramco 
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HRStream  3.0 

Oracle 
HRMS  1.0 

PeopleSoft 
HRMS  4.0 

Marshal  1.0 

R/3  2.2 
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B 

C 
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HR 

B 

B 

A 

B 

N/A 
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A 
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A 
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C 
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A 

A 

C 

C 
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Tax 
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A 

A 

A 
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D 

B 

A 

F 

D 

References 

B 

B 

A 

A 

B 

Willing  to  fully  demo  products  (including  beta) 

D 

A 

A 

B 

D 

Quality  of  interaction  w/vendor 

B 

A 

A 

D 

F 

GPA 

2.6 

2.7 

3.8 

22 

u 

WEEKLY  GRIND 

Tliat  just  Wasn't joing  to  happen  with  the  legacy  system,  as  is  or  upgraded.  Back  in  1989, 
when  Si's  temp  operation  was  much  smaller,  the  company  bought  a  NetWare  LAN-based 
accounting  system  from  Platinum  Software.  Then  it  built  a  payroll  system  for  it  with  PC 
Magic,  a  4GL  modified  to  incorporate  Platinum's  data  structure.  Everything  worked 
in  character  mode  or  paper  forms. 

By  1994,  the  system  was  taking  a  week  to  grind  out  each  week's  payroll  for  an  average  of 
6,500  workers.  The  programmers  complained  that  Magic's  architecture  rivaled  mainframe 
=  r  sySfigmis  for  rigidity.  The  system  lacked  an  automatic  interface  between  payroll  and 
financials.  The  system  couldn't  consolidate  automatically  across  business  units.  There 
was  no  provision  for  decision  support.  And  payroll  was  so  customized  that  SI  couldn't 
keep  up  with  Platinum  updates.  Nor  did  they  see  Platinum  For  SQL  (Platinum's  own 
upgrade  product),  as  a  possible  solution.  Platinum  didn't  offer  payroll,  and  as  it  was 
refocusing  on  its  core  financials,  the  future  was  unclear  for  Platinum's  HR  package,  too. 

In  late  1993,  Bob  Snelling  Jr.,  senior  VP  of  IS,  and  Buck  Buchanan,  VP  of  IS,  teamed  up 
to  start  looking  for  a  better  way.  They  wanted  to  know  who  had  integrated 
HR/payroll/financials.  They  got  an  initial  list  of  over  100  such  vendors  from  the 
American  Payroll  Association.  They  got  to  work  on  the  phone  calling  the  vendors, 
perused  HR  trade  magazines,  checked  out  HR  trade  shows,  and  worked  up  an  RFP. 

Snelling  says  60  of  those  vendors  said  they  thought  they  had  a  product  that  fit  Si's  needs, 
but  he  and  Buchanan  quickly  found  themselves  dealing  seriously  with  only  a  handful  of 
vendors.  And  "as  we  kept  boring  in  on  them,  giving  them  more  requirements,  more 
stopped  calling  us  or  told  us  to  go  with  others,"  says  Snelling.  At  the  behest  of  top 
management,  Snelling  and  Buchanan  had  confined  their  search  to  employment  agency 
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verticals  and  were  trying  to  find  something  that  ran  on  the  AS/400  or  NetWare  LAN  they 
already  had.  These  products  were  much  cheaper  than  mainstream  client/server  products. 

Snelling  and  Buchanan  both  believed  the  company  needed  a  modem  client/  server 
package,  but  company  executives  weren't  so  sure,  and  they  were  used  to  making  decisions 
and  handing  them  off  to  IS  to  implement.  Snelling  needed  to  move  IS  out  of  the  hired 
hands  category  before  the  company  wound  up  with  a  system  that  wasn't  actually  new  and 
wouldn't  carry  SI  into  the  future  properly. 

The  change  was  so  huge  that  Snelling  knew  a  simple  decree  wouldn't  work-even  coming 
from  a  senior  VP  and  son  of  the  chairman.  "I  could  have  gone  out  by  myself  as  senior  VP 
of  IS  and  made  the  decision,"  he  says.  "But  I  knew  there  would  be  tough  times  during 
conversion  and  installation.  Then  people  would  say,  "He  doesn’t  know  what  he's  doing' 
or  "He’s  getting  kickbacks.'  So  we  had  to  include  everyone.  That  way,  when  the  tough 
times  come,  they  have  to  say  "Yes,  this  is  tough.  But  there's  no  way  around  it.'" 

So  Snelling  did  a  Texas  two-step.  First,  he  included  everyone  from  the  chairman  of  the 
board  to  the  staff  accountants  in  payroll  in  each  vendor  evaluation.  Second,  he  brought  in 
a  reputable  consulting  organization,  CSC— not  for  specific  product  recommendations,  but 
for  strategic  direction.  "We  had  CSC  educate  upper  management  on  the  way  technology 
was  heading,"  says  Snelling.  CSC  convinced  them  that  SI  had  to  go  client/server  and  to 
reject  any  HRMS  products  that  weren’t.  This  was  what  Snelling  and  Buchanan 
had  already  told  them  for  free,  but  it  was  money  well  spent. 

"My  most  difficult  challenge  with  IS,"  Snelling  says,  "was  to  politely  get  the  executives  to 
understand  that  they  didn't  know  what  was  best  for  the  company  in  automation"  and  that 
IS  did  know.  CSC  helped  Snelling  accomplish  both  of  these  delicate  tasks.  It  also 
addressed  the  issue  of  reautomating  Si's  headquarters  in  general.  SI  had  multiple 
databases  of  information  about  franchises.  If  a  franchise  address  changed,  it  required 
multiple  manual  updates.  The  need  to  update  payroll  and  Unancials  and  acquire  HR 
software  had  to  be  seen  in  this  perspective,  not  as  a  set  of  disconnected  issues.  "We 
needed  a  consulting  company  to  help  save  us  from  making  multimillion-dollar  mistakes," 
Snelling  concludes.  CTRL-ALT-DEL 

After  seeing  eight  vertical  vendor  demos  and  hearing  out  CSC,  Snelling  and  Buchanan— 
and  everyone  else— whittled  the  list  down  to,  well,  zero.  Just  as  Snelling  and  Buchanan 
had  predicted,  none  of  these  products  would  do.  They  offered  little  more  than  payroll  and 
couldn't  handle  the  complexity  and  scale  of  Si's  operations. 

So  they  started  over,  this  time  looking  for  mainstream  client/server  HR  products.  They 
went  back  to  the  initial  list  of  100  and  to  the  mainstream  computer  press,  especially  for 
information  about  new  products,  like  Ramco's  Marshal  Human  Resource  Management. 

All  in  all,  SI  talked  to  29  companies  on  the  second  pass.  Lots  of  vendors  backed  out  fast 
because  of  the  complexity  and  scale  of  Si's  needs  or  because  their  suites  of  client/server 
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tools  were  incomplete.  Si's  requirements  list  had  grown  to  over  247  line  items,  covering 
systems,  security,  data,  check  processing,  payroll  processing,  taxes,  error 
adjustments,  reporting,  human  resources,  accounts  receivable,  and  workers' 
compensation.  Other  specific  HR  requirements  included  insurance;  EEOC;  new-hire 
tracking;  tracking  I-9s,  W-4s,  and  W-5s;  tracking  vacations  and  holidays;  benefits; 
training  skills/experience;  job/work  experience;  and  r,sum,  information. 

SI  needed  to  be  able  to  track  training,  both  for  job  skills  and  government-mandated  safety 
training.  And  to  coippete  for  the  best  temps,  SI  needed  to  be  able  to  offer  benefits,  which 
the  HR  system  had  to  monitor  and  manage. 

The  requirements  list  was  intimidating  enough.  But  the  flaming  hoop  Snelling  and 
Buchanan  devised  for  the  contenders  came  from  the  depths  of  payroll;  garnishment 
management. 

Garnishments  have  been  a  nightmare  for  SI.  A  lot  of  temps  have  multiple  garnishments 
from  multiple  counties— or  even  states— for  everything  from  child  support  to  loan 
repayments.  Multiple  legal  judgments  sometimes  mandate  dollar  amounts  that,  taken 
together,  exceed  the  temp's  pay.  If  that  happens,  the  software  has  to  figure  out  how  much 
goes  to  whom  based  on  percentages  determined  in  court  judgments  and  limits  as  to  how 
little  you  can  leave  an  employee  with. 

Rules  vary  from  state  to  state,  and  you  have  to  figure  in  reciprocity  laws  between  the 
states  when  more  than  one  is  involved.  A  temp  may  live  in  one  state  and  work  in  a 
second;  the  SI  office  may  be  in  the  first  state,  the  second  state,  or  even  a  third.  To  make 
things  even  worse,  some  temps  try  to  beat  the  system  by  having  extra  withholding  taken 
-out  to  artificially  depress  their  pay.  The  software  needs  to  spot  that  and  deduct 
garnishments  before  the  extra  withholdings. 

Snelling  and  Buchanan  gave  the  vendors  real-life  garnishment  scenarios  to  compute, 
involving  multiple  job  assignments  and  figuring  which  and  how  much  would  come  out 
for  child  support,  home  appliance  payments,  utility  bills,  Texas  state  taxes,  and  more. 

i 

Buchanan  says  that  a  lot  of  vendors  just  didn't  t^e  these  complexities  into  account  when 
they  designed  their  software.  When  confronted  with  Si's  garnishment  deductions  test,  | 

several  vendors  said  that  the  scenarios  were  ridiculous.  Buchanan  retorted  that  not  only  j 

could  he  show  them  numerous  real  examples  but  Si's  own  homebrew  package  j 

could  handle  them.  And  SI  laid  a  trap  for  unsuspecting  vendors.  Remember  those  Texas  j 

state  taxes  that  had  to  be  figured  in?  Well,  Texas  doesn’t  have  state  taxes.  "We  were  { 

sneaky  about  it,"  Snelling  laughs.  He  adds  that  most  of  the  vendors  made  up  a  tax  amount  | 

anyway,  so  the  trap  worked.  I 

I 

About  18  vendors  took  the  garnishment  test:  10  vertical  packages  and  eight  client/server. 

All  of  the  vertical  packages  failed  miserably,  others  came  closer,  but  not  close  enough.  "A 
lot  of  software  packages  just  didn't  work  right"  on  garnishments,  Buchanan  says,  adding 
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that  Oracle's  chief  of  research  and  development  decided  to  revise  Oracle's  approach  to  the 
problem  based  on  the  results  of  the  test.  Computer  Associates  said  its  CA-HRISMA 
software  could  handle  it,  but  failed  to  provide  anything  like  the  right  amounts  in  several 
tries.  In  some  cases,  the  software  prompted  for  the  amounts,  then  ignored  them.  Only 
PeopleSoft  HRMS  got  the  right  answers  and  w  as  able  to  handle  interstate  reciprocity 
laws. 

What's  so  Client/Server  about  HRMS? 

ULTIMATELY,  NO  CONTEST 

Buchanan  says  that  PeopleSoft  HRMS  outshone  its  competitors  elsewhere,  as  well.  "I 
don't  think  any  of  the  other  vendors’  packages  were  quite  comparable,"  says  Buchanan. 
"PeopleSoft  had  all  the  pieces  and  more  effective  tracking."  The  SI  team  loved  all  of  the 
tables  that  came  with  it.  In  fact,  according  to  Snelling,  "the  winner  in  everyone's  mind 
from  early  on  was  PeopleSoft.  The  comments  after  every  review  of  the  product  went 
"Boy,  if  we  won  the  lottery,  it  would  be  great  to  have-but  so  expensive.'" 

The  serious  finalists  to  emerge  from  Si's  gauntlet  were  D&B  HR  Stream  3.0,  Oracle's 
Oracle  HRMS  1.0,  PeopleSoft  HRMS  4.0,  Ramco's  Marshal  1.0,  and  SAP  R/3  2.2.  And  it 
turned  out  they  were  all  in  PeopleSoft's  price  bracket.  After  some  soul-searching,  the 
executive  team  decided  to  expand  the  buying  budget.  Funds  also  had  to  be  allocated 
for  upgraded  hardware  and  the  customization  needed  to  adapt  a  broadband  package  to  Si's 
specific  needs.  The  most  important  change  involved  a  standard  procedure  for  a  temp  help 
agency:  After  SI  pays  a  temp,  it  has  to  invoice  the  client,  then  pay  the  franchi~see  after 
deducting  Si's  royalty  and  other  moneys  owed  from  each  franchise's 
individual  agreement.  The  verticals  did  all  that,  of  course.  So  it  meant  that  Snelling  and 
Buchanan  needed  to  look  at  each  vendor's  customization  capabilities  closely. 

PeopleSoft  uses  a  proprietary  toolset  called  PeopleTools  along  with  COBOL  and  C. 
Oracle  and  SAP  use  proprietary  4GLs.  Ramco  uses  VC-H-,  a  3GL.  Buchanan  compared 
PeopleTools  to  PowerBuilder  (D&B's  tool),  and  found  it  not  as  complete.  But  COBOL 
batch-processing  support  made  up  for  that  by  not  forcing  everything  to  go  through  a 
screen  interface.  Buchanan's  biggest  worry  about  using  the  4GLs  in  general  was  that  they 
would  make  it  easy  for  someone  to  go  in  and  mess  things  up. 

SI  also  seriously  considered  the  treatment  it  had  received  from  the  vendors.  Some  vendors 
put  their  cards  on  the  table,  while  others  treated  Si's  team  like  mushrooms;  they  showed 
off  glossy  color  brochures  that  implied  products  in  development  were  actually  complete. 
Some  were  more  interested  in  dishing  dirt  on  the  competition  than  in  showing  off  their 
own  stuff. 

Snelling  did  note  that  PeopleSoft's  one-SQL-call-fits-all  approach  precluded  the  stored 
procedures  and  triggers  needed  for  optimum  performance.  But  he  was  resigned  to  having 
his  staff  code  those  in  order  to  get  PeopleSoft's  other  advantages.  He  also  accepted  the 
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need  to  support  it  with  fast  hardware,  figuring  those  costs  into  his 

calculations.  Ultimately,  he  could  accept  slower  performance  when  it  was  coupled  to 

superior  functionality  and  friendliness. 

TELLING  INSIGHT 

Reference  checking  and  site  visits  were  telling.  "The  first  time  we  visited  a  PeopleSoft 
site,  we  thought  we  had  somebody  who  maybe  got  paid  under  the  table,"  Snelling  said. 
"But  every  single  site  we  talked  to  raved  about  the  product  and  its  implementation.  They 
said  yes,  it’s  pricey,  but  worth  it.  The  Oracle,  SAP,  and  D&B  sites  said  they  liked  it,  it 
worked  well.  But  they  weren't  raving." 

If  SI  chose  Oracle  or  Ramco,  Snelling  knew  he'd  be  working  as  a  beta  site  and  to  some 
extent  as  a  codeveloper.  He  didn't  want  to  chance  it  with  Ramco,  which  was  new  to  this 
country,  but  he  did  get  close  to  doing  that  with  Oracle,  since  SI  had  opted  for  Oracle's 
database.  SI  ultimately  decided  not  to  become  a  beta  guinea  pig. 

Snelling  even  had  the  brass  to  call  Si's  25  chief  competitors  and  ask  them  what  they  used. 
Surprisingly,  "18  were  quite  open  with  me,"  he  says.  Three  of  them  had  already  bought 
PeopleSoft,  and  Snelling  feels  this  would  give  them  all  clout  with  PeopleSoft  on  issues 
common  to  their  industry. 

The  Bnancials  weren’t  ready  by  the  time  SI  signed  the  contract  in  late  December,  but 
Snelling  was  confident  that  they’d  be  ready  by  the  time  SI  was  ready  to  install  them.  The 
fact  that  PeopleSoft  had  always  been  aboveboard  about  where  it  was  on  each  piece  helped 
build  that  confidence.  However,  Snelling  would  have  bought  PeopleSoft's  HR/payroll 
package  and  someone  else's  financials  if  need  be. 

Ordinarily,  "a  corporate  headquarters  with  140  employees  is  never  in  100%  agreement  on 
anything,"  says  Snelling.  "When  it  comes  to  software,  there  are  people  who  staunchly 
defend  their  favorites.  But  from  the  chairman  who’ll  never  have  to  use  this  software  to  IS 
programmers  and  system  analysts  to  payroll  tax  department  executives  to  managers  and 
staff-it  was  a  unanimous  decision. 
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DEFENSE  SCIENCE  BOARD  MILITARY  PERSONNEL 
AND  PAY  SYSTEM  TASK  FORCE 
COMMERCIAL  OFF  THE  SHELF  (COTS) 
FEATURE  COMPARISON  CHARTS 


These  Feature  Comparison  Charts  provide  you  a  guide  to  look  at  competitive  commercial  off  the  shelf 
products  (COTS)  in  your  selection  process.  As  you  look  at  the  competitive  products  Chart  #1 ,  you  see 
that  Product  A  provides  you  all  of  the  features  needed  for  Distributed  Client/Server  applications  at  25% 
less  cost.  Chart  #2  contains  the  summary  advantages  of  your  selection.  Although  these  Feature 
Comparison  Charts  are  provided  as  examples  only,  they  contain  the  principal  features  required  for  an 
integrated  single  military  pay  and  personnel  system. 
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Feature  Comparison  Chart  #1 


Feature 

A 

B 

iiiobai  Issues: 

Compiled  code  support 

No 

X 

16  and  32-bit  application  creation 

X 

Full  object-oriented  support: 


-  Class  Libranes 


-  Encapsulation 


•  Function  Overioadin 


-  Multi-level  inheritance 


Windows  3.1,  NT,  OSF/Motif,  Macintosh, 
character  mode. 


Windows  95,  Windows  3.x,  NT,  DEC 
Alpha  NT,  Mac,  UNIX  (Sun  Solaris) 


lication  Partitionin 


C++  Class  Builder 


Class  Library  (Pre-built  objects,  sample 
framework  &  services  via  the 
Foundation  Class  library) 


Central  design  repository  for  defining 
and  storinq  extended  attributes 


Configuration  Management 


Database  engine  (included 


Database  stored  procedure  and  trigger 


Database  interoperability  &  scalability  to 
Sybase  SQL  Server  for  full  enterprise 
deployment 


Limited:  Can  call  DLLs,  but  cannot 
_ support  the  language 


Oracle  RDBMS  (native  access)  and 
ODBC-  only  connectivity  to  non-Oracle 
databases 


Data  paipeline  for  data  conversion  & 
migration  between  databases 


DDE 


Native  Access  to:  Oracle,  Sybase : 
Server,  BM  DRDA,  Informix  SE,  Informix 
Online,  MDI  Gateway  for  DB/2,  Microsoft 
SQL  Server,  and  ODBC  connectivity  to 
Btrieve,  IBM  DB2,  DB2  for  AS/400,  dBase 
II  III  IV  V,  Excel,  Netware  SQL,  Paradox, 
Text, 

Sybase  SQL  Anywhere 


Library  for  Lotus  Notes 


Object  browser  (including  OCXs 


Object  management 


ODBC  version  2 


OLE  2.0  custom  control  (OCX)  Support 


OLE  2.0  extended  support 


-  Plug  &  Play  with  any  OCX 


-  OLE  automation  -  OLE 
automation  servers 


-  OLE  server-enabled  DataWindow 


-  Point  &  click  SQL  interface  to  OLE 


Ms.  Padalino’s  memo  with  SYBASE  input 
to  the  Defense  Science  Board  Task  Force  on 
Military  Personnel  Information  Management 
Report  BAFO,  (8/7/96) 
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7-Aug-1996 


I  Sybase* 


OUSD(PNR)  R&R-IM 
Attn:  Norma  St.  Clair 
4015  Wilson  Blvd. 

Suite  1212 
Arlington,  Va.  22203 

Subject:  Criteria  for  selecting  COTS  software  for  DoD-wide  Personnel  and  Payroll 
Dear  Ms.  St.  Clair: 

Sybase  is  pleased  to  have  the  opportunity  to  provide  this  input  on  criteria  for  selecting  a 
COTS  application  for  the  DoD’s  Personnel  and  Payroll  requirements.  Although  Sybase 
does  not  directly  produce  software  for  Personnel  and  Payroll,  our  open  database 
management,  middleware,  and  application  development  tools  provide  the  technology 
foundation  for  many  of  the  industry's  leading  COTS  application  vendors.  The  criteria 
these  COTS  applications  vendors  used  in  selecting  Sybase  products  as  their  foundation 
technology  was  driven  by  their  customer’s  needs.  It  is  that  criteria  described  herein  and 
also  the  criteria  that  will  best  help  the  DoD  in  selecting  a  COTS  Personnel  and  Payroll 
application  with  the  lowest  life-cycle  cost  and  shortest  implementation  time. 

Criterion  1  -  Open  Database:  The  COTS  application  should  run  "natively"  with  multiple 
SQL  RDBMSs,  including  either  the  big  four—  e.g.,  Sybase,  Informix,  Oracle,  Microsoft— 
or,  at  a  minimum,  the  two  specified  in  the  Defense  Information  Infrastructure  (DII) 
Common  Operating  Environment  (COE)  published  by  DISA-  e.g.,  Sybase  and  Oracle. 
This  means  that  the  application  can  directly  run  on  a  choice  of  RDBMSs  without  any 
performance  loss  or  redundant  data  storage  requirement.  COTS  applications  that  require 
a  proprietary  vendor  file  system  or  specific  RDBMS  to  natively  store  data  and  then 
redundantly  copy  data  to  other  RDBMSs  do  not  meet  the  Open  Database  criterion. 
Selecting  a  COTS  Personnel  and  Payroll  application  should  in  no  way  force  you  to  select 
or  standardize  on  a  single  database. 

Open  Database  support  would  benefit  the  DoD  primarily  through  cost  savings  in  two  key 
areas:  1.)  those  accrued  from  competition  in  acquisition  organizations  need  to  purchase  a 
new  RDBMS  to  run  the  COTS  application  and  2.)  those  associated  with  organizations 
being  able  to  re-use  their  existing  inventoiy  of  NAME  and  save  cm  purchase  and  re¬ 
training  costs.  Secondarily,  adoption  of  the  Open  Database  criterion  would  benefit  the 
DoD  through  the  inherent  benefits  from  the  flexibility  provided  by  a  choice  of  SQL 
RDBMSs—  these  included  leverage  over  vendors  to  provide  first  rate  support  or  risk  swap 
out,  and  the  ability  for  the  DoD  to  select  the  best  of  breed  RDBMS  at  the  time  of  deploy 
given  that  title  will  continue  to  change  hands  quite  regularly  over  the  period  of 
deployment. 
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Criterion  2  -  Open  Tools:  The  COTS  application  should  be  built  upon  and  modiriable 
with  open  application  development  tools  that  support  rapid  application  development, 
facilitate  managed  re-use,  and  are  widely  used  in  industry  as  well  as  the  DoD.  The  Open 
Tools  criterion  requires  that  the  COTS  application  toolset  run  "natively"  with  multiple 
SQL  RDBMSs  for  the  same  reasons  listed  above  for  the  Open  Database  criterion  and  for 
the  additional  reason  that  non-native  interfaces,  such  as  the  Open  Database  Connectivity 
(ODBC),  do  not  meet  the  performance  requirements  of  large,  complex  applications  like 
those  of  the  DoD’s  Personnel  and  Payroll  would  applications. 

The  additional  benefits  of  the  DoD  adopting  the  Open  Tools  criterion  (i.e.,  over  and 
above  the  benefits  described  under  the  Open  Database  criterion)  are  in  two  areas:  1) 
training  and  personnel  cost  savings  and  2)  in  development  time  savings.  By  selecting  a 
COTS  application  that  employs  a  toolset  that  is  widely  used  in  industry  and  government, 
the  DoD  will  find  it  much  less  costly  to  find,  train,  and  acquire  personnel  resources  with 
sufficient  expertise  in  the  required  locations.  The  also  speed  up  its  development  effort  as 
it  wouldn’t  have  to  spend  time  and  moneys  to  train  its  staff  or  contractors  in  the  use  of 
vendor-proprietary  toolsets.  Finally,  the  DoD  would  benefit  in  cost  and  development 
time  savings  from  the  "rich  and  robust"  third-party  market  for  software  development 
environments  and  productivity  enhancements  that  are  ever-present  around  industry- 
standard  toolsets. 

Sybase  realizes  that  the  DoD  will  need  to  consider  many  other  criteria  (such  as 
functionality  fit  with  DoD’s  requirements,  vendor  market  share,  ease  of  modification, 
etc.)  in  selecting  a  Personnel  and  Payroll  application.  The  above  described  Open 
Database  and  Open  Tools  criteria  will  ensure  the  technological  underpinnings  of  the 
selected  Personnel  and  Payroll  application  are  consistent  with  DoD’s  objectives  for 
selecting  COTS—  life-cycle  cost  savings  and  minimized  implementation  times. 

Should  you  have  questions,  do  not  hesitate  to  contact  me  at  301/896-1757.  Thank  you  for 
giving  Sybase  this  opportunity  to  participate  in  this  important  Defense  Science  Board 
action. 


Account  Manager 
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Defense  Science  Board  Task  Force  on  Military 
Personnel  Information  Management 
Report .  BAFO,  (8/7/96) 


A-6-1 


This  Page  Intentionally  Left  Blank 


SGRC 

IHH  international  INC 


1900  Gallows  Road  Vienna,  Virginia  22182  (703)506-5000 


August?,  1996 


Chairman,  Defense  Science  Board 

do  Norma  J.  St.  Claire  Personnel  and  Readiness  Office  of  the  Under  Secretary  of  Defense 
4015  Wilson  Blvd.,  Room  204 
Arlington,  VA  22003 

Reference:  input  to  the  Military  personnel  Information  Management  Task  Force  Report 

The  purpose  of  this  memo  is  to  provide  observations  regarding  EC  role  of  adapting  a 
COTS  solution  for  the  MPM21  Objective  System  and  the  degree  to  which  that  solution 
may  simplily 

design/development  tasks,reduce  timelines  and  save  money. 

Clearly,  there  are  good  analogies  in  the  business  community  that  demonstrate  the 
effective  use  of  COTS  solutions  for  integrated  personnel  and  payroll  systems.  It  would  be 
in  the  government’s  best  interest  to  explore  several  of  the  most  relevant  solutions  so  that  a 
fiill  range  of  alternatives  may  be  understood  and  valuable  information  gained  from  these 
industry  experiences. 

It  should  be  noted,  however,  that  me  MPM21  Objective  System  will  need  to  satisfy  a 
demanding  range  of  requirements,  including: 

-  Integration  of  active,  reserve,  and  reserve  components, 

-  Ability  to  scale  solutions  so  that  they  provide  effective  functionality  to  every 
operational 

level  from  detachment  to  top  of  the  system, 

-  Ability  to  accommodate  multiple  hardware/software  suite  combinations  at  eveiy  level, 

-  Ability  to  integrate  across  personnel  and  pay  functions  as  well  as  share  data  with  other 
functional  area  systems  (i.e.,  logistics,  medical), 

-  Ability  to  accommodate  wartime  and  peacetime  operational  environments, 

-  Ability  to  integrate  with  legacy  systems,  and  to  interoperate  and  share  data  with  other 
enterprise  systems  on  the  DII. 

Determining  the  ability  of  COTS  products  to  address  all  of  these  requirements  is  critical 
to  program  planning.  A  gap  analysis  may,  show  how  much  functionality  comes  "out  of 
the  box",  but  equally  important  is  the  complexity  of  functionality  not  addressed  by  COTS 
products.  The  tailoring  and  extension  of  COTS  software  to  meet  MPM21  requirements 
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may  test  the  engineering  rule-of-thumb,  which  is  that  it  takes  90%  of  the  development 
cycle  to  achieve  the  last  10%  of  critical  functionality.  Only  a  full  laydown  of  essential 
requirements  can  lead  to  that  determination.  As  a  result,  shortening  of  the  timelines  due 
to  adapting  a  COTS-based  solution  may  make  it  infeasible  to  provide  a  system  that  meets 
all  of  the  stated  requirements. 

Additionally,  a  series  of  fundamental  technical  issues  must  be  evaluated  before  a  program 
timeline  and  life-cycle  cost  estimate  can  be  established  with  reliability.  These  issues 
include:  the  degree  of  COTS  tailoring  needed;  the  amount  of  new  software  necessary  to 
meet  functionality  not  addressed  by  COTS;  the  complexity  of  integrating  new  modules 
with  COTS  products;  performance  trade-offs  of  running  a  hybrid  COTS/designer 
software  system  on  all  hardware/software  suites  used  by  MPM21;  and  the  maintenance  to 
support  modified  COTS,  new  software,  and  integration  software  products  created  to 
support  this  project. 

COTS  packages  often  incorporate  industry  best  practices  and  provide  excellent 
functionality.  Leveraging  existing  COTS  software  may  shorten  the  application 
development  portion  of  the  system  schedule,  however,  industry  metrics  show  that  less 
than  20%  of  project  costs  are  expended  developing  code,  while  integration  tasks  can 
consume  close  to  25%  (derived  from  case  studies  used  in  Checkpoint  project  costing 
software  developed  by  Software  Productivity  Research,  Inc.).  Tailoring  and  integrating 
COTS-based  applications  into  enterprise  environments  present  unique  management  and 
technical  issues  distinct  from  traditional  development  efforts.  Based  on  our  experience 
participating  in  the  development  of  other  large  DoD  enterprise  systems,  such  as.  Joint 
Computer-Aided  Acquisition  and  Logistics  Support  (JCALS)  System,  Reserve 
Component  Automation  System  (RCAS),  and  the  Defense  Investigative  Service  (DIS), 
we  have  confirmed  that  the  integration  of  COTS  can  be  more  complex  than  fairly  well- 
defined  application  development  segments  and  as  a  result,  can  have  a  significant  impact 
on  the  system  development  schedule. 

We  agree  that  COTS  solutions  should  be  vigorously  pursued  for  MPM21.  By  using 
proven  COTS  products  to  satisfy  mission  requirements,  DoD  will  realize  significant 
benefits  by  leveraging  complete  and  tested  products  for  its  functional  modules.  Before 
enterprise-wide  deployment,  however,  it  is  important  to  prototype  and  benchmark  these 
COTS-based  solutions.  The  purpose  of  this  benchmarking  effort  is  threefold.  First,  it  can 
be  used  to  update  the  objective  system  architecture  by  providing  valuable  information  on 
the  degree  to  which  COTS  software  meets  requirements  and  by  identifying  new  software 
modules  that  are  needed  to  realize  full  functionality.  Second,  it  can  be  used  to  identify 
the  full  scope  of  system  integration  tasks  and  validate  the  COTS-integration  process. 

Third,  it  will  help  define  a  standard  method  for  implementing  interfaces  to  legacy 
systems,  as  well  as  achieving  interoperability  and  data  sharing  with  core  DII  systems 
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(i.e.,  GCSS).  Accordingly,  the  initial  COTS  initiatives  should  be  viewed  as  interim 
solutions  that  can  be  fully  exercised  by  all  services  to  validate  the  utility  of  the  product 
and  to  help  prioritize  the  addition  of  greater  functionality.  Lessons  learned  from  these 
efforts  can  be  incorporated  into  the  final  objective  system  through  an  aggressive  product 
improvement  program  which  gives  the  added  benefit  of  reinforcing  user  confidence  by 
incrementally  proving  the  value  of  progressively  enhanced  system  updates. 

We  understand  that  an  incremental  development  approach  may  be  more  time  consuming 
than  originally  envisioned.  Lessons  learned  from  past  and  current  large-scale 
development  efforts,  however,  demonstrate  to  us  and  our  government  clients  that  a 
progressive  development  plan  offers  the  highest  chance  of  success  in  fielding  a  system 
that  responds  to  the  complex  requirements  that  an  MPM21  objective  system  must 
address. 

Thank  you  for  the  opportunity  to  provide  this  input.  Building  a  DoD  enterprise  military 
personnel  system  demands  the  best  industry  can  offer.  We  realize  the  magnitude  of  the 
challenge  faced  by  the  Defense  Science  Board  and  DoD  in  this  endeavor  and  we  would 
be-happy  to  provide  further  details  or  respond  to  questions  that  might  arise  from  our 
observations.  If  we  can  provide  additional  information  please  call  Paul  Schuessler  at 
506-5336. 
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Ms.  Norma  St.  Claire 
OSD,  Personnel  &  Readiness 
4015  Wilson  Blvd  Ste  1212 
Arlington,  VA  22203 


Dear  Norma: 

On  behalf  of  Oracle  Government,  I  am  pleased  to  provide  our  final  observations  and  input 
concerning  the  Defense  Science  Board  Task  Force  on  Military  Personnel  Systems. 
Attached  is  our  two(2)  page  input. 

Also,  included  is  the  clarification  to  question  8. 


Vice  President 
Oracle  Government 


JP/rp 


enclosure(s) 


Recommendations  to  the  Defense  Science  Board  (DSB). 


As  a  leading  developer  and  provider  of  information  technology  and  services,  Oracle 
would  like  to  take  the  opportunity  to  advise  the  DSB  in  the  area  of  COTS  software. 

Oracle  believes  that  the  following  evaluation  points  are  a  viable  litmus  test  for  any  vendor 
under  consideration  to  fulfill  DoD  requirements.  Although  the  genesis  of  this  document 
is  the  evaluation  of  COTS  HR  systems  and  their  applicability  to  the  DoD,  the  following 
recommendations  are  valid  for  the  full  spectrum  of  COTS  applications,  i.e.  financials, 
payroll,  manufacturing,  inventory,  etc. 

The  DoD  should  assess  their  current  investment  in  information  technology  for  the 
HR  domain.  The  integration  of  COTS  HR  with  current  development  environments 
in  DOD  should  be  maximized  in  order  to  reduce  cost  and  overall:  time  of 
implementation  and  leverage  existing  infrastructure  investment. 

There  should  be  an  acknowledgment  of  the  compelling  business  case  for  DOD,  the 
Services  and  the  taxpayer  through  the  use  of  core  COTS  HR  in  conjunction  with  an  open, 
non-proprietary,  portable  and  widely  used  development  environment  (RDBMS  &  tools). 
Additionally,  this  business  case  should  include  documentation  of  the  lower  life  cycle 
costs  of  ongoing  efforts  in  "customized"  COTS  to  support  continuous  improvement  in  an 
area  of  accelerating  change  and  fiscal  constraint.  This  assessment  should  be  measured 
using  the  metrics  of  both  dollars  and  time.  With  which  vendors  has  the  DoD  obligated 
most  of  their  funding?  For  a  responsible  vendor,  a  significant  investment  translates  into  a 
superior  level  of  customer  support.  In  which  vendors  products  are  the  most  developers 
and  contractors  trained?  An  established  base  of  trained  personnel  keeps  the  learning 
curve  shorter,  allowing  more  time  for  productive  system  development.  These  factors 
weigh  heavily  in  the  likelihood  of  success. 

The  DoD  should  select  scaleable,  open  systems  components  for  their  HR  systems. 
One  of  these  components  must  be  an  extensible  HR  product  and  a  payroll  product 
which  can  be  seamlessly  integrated  at  the  DOD  or  service  level,  as  well  as  proven 
implementation  methodology  and  services  capability. 

One  of  the  keys  to  achieving  success  with  the  DoDs  HR  customers  is  the  ability  to 
effectively  support  the  entire  enterprise;  from  small  workgroups  to  larger  departmental 
organizations  as  well  as  providing  agency  level  visibility.  As  we  have  seen,  organizations 
are  routinely  downsizing  and  upsizing,  commands  are  merging  or  dispersing.  Scalabilty 
needs  to  be  defined  as  both  the  ability  for  the  system  to  seamlessly  and  rapidly  increase  in 
size  or  scale  down  based  upon  customer  requirements.  A  rapid  transition  from  an  in¬ 
garrison  configuration  to  a  contingency  operation  should  be  achievable  without 
diminished  capability.  Additionally,  specific  hardware,  networking,  operating  systems, 
etc.  should  not  be  a  gating  factor  in  the  scalability  decision.  The  DoD  should  select  open 
systems  components  which  afford  the  agility  to  move  to  new  technology  with 
price/performance  benefits  without  an  onerous  transition  cost.  Most  current  legacy 
systems  deliver  the  functionality  required  at  the  time  they  were  specified.  However, 
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infusing  new  technology  into  these  systems  is  generally  difficult  and  prohibitively 
expensive.  DoD  customers  demand  GUI  applications,  Web  integration  and  other 
relatively  new  technologies  from  their  systems. 

The  DoD  should  identify  a  COTS  HR  provider  who  is  able  and  willing  to  participate 
in  a  proactive  partnership  with  DOD  and  has  the  corporate  size,  market  experience 
and  staying  power  to  share  in  the  development/integration  of  core  and  unique  DOD 
military  personnel  system  components. 

The  COTS  provider  must  consider  the  effort  as  equally  important  to  their  business  as  the 
DoD.  They  must  have  the  corporate  size,  market  share  and  commitment  to  share  in  the 
development  effort.  The  COTS  provider  must  also  be  able  to  assist  in  the  migration  of 
DOD  and  its  components  to  best  practices  in  personnel  management/HR  across  national, 
industry  and  intergovernmental  boundaries  by  affiliation  with  a  global  partner  who 
provides  the  experience  and  customer  base  to  achieve  this  critical  objective. 

The  DoD  should  initiate  the  expeditious  development  of  service  functional 
requirements  in  a  standard  repository  which  allows  for  easy  comparison  and  rapid 
determination  of  common  requirements,  (extension  of  JWG  process). 

The  MPM  21  initiative  should  be  used  to  drive  towards  the  greatest  degree  of  common 
requirements.  The  fewer  service  unique  requirements  that  exist,  the  less  duplicate 
development  efforts  will  need  to  take  place. 

The  following  are  Oracle’s  perspective  on  the  recommendations. 

The  DoD  should  assess  their  current  investment  in  information  technology  for  the 
HR  domain... 

The  DoD  through  their  efforts  with  the  Air  Force  at  San  Antonio,  the  Navy  at  New 
Orleans  has  spent  millions  dollars  with  Oracle.  These  procurements  have  been  used  to 
fund  software,  training  and  support.  As  a  result,  there  is  an  Oracle  HR  knowledge  base  in 
DoD  that  far  exceeds  that  of  any  other  COTS  HR  provider.  From  a  core  technology 
perspective,  Oracle  maintains  a  70+%  market  share  of  the  relational  database  market 
within  the  federal  government.  This  market  share  ensures  that  government  requirements 
maintain  high  visibility  within  Oracle. 

The  DoD  should  select  scaleable,  open  systems  components  for  their  HR  systems... 
Oracle  is  portable  and  scaleable  to  a  wide  range  of  hardware  environments  and 
architectures.  All  DoD  standard  contract  hardware  and  operating  system  platforms  can 
run  Oracle  HR.  Oracle  is  still  the  only  vendor  that  can  provide  identical  core  technology 
from  the  desktop,  through  the  workgroup  server  market  up  to  and  including  enterprise 
level  computing  environments.  Additionally,  Oracle  supports  over  90  different  hardware 
and  operating  system  combinations  as  well  as  a  wide  variety  of  networking  topologies. 

The  transition  from  UNIX  to  NT  to  Windows  is  little  more  than  an  export  and  import  of 
data.  Oracle’s  Open  Gateways  and  APIs  provide  an  environment  which  over  3,500 
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vendors  have  used  to  develop  products  which  integrate/interoperate  with  the  Oracle 
product  set.  Oracle's  Open  Gateway  technology  allow  for  the  transparent  integration  of 
non-Oracle  data  including;  Sybase,  Informix,  DB2,  VSAM,  APPC,  etc. 

Oracle  maintains  an  enviable  list  of  industry  firsts  from  the  first  commercially  available 
SQL  RDBMS  to,  most  recently,  web  integration-  This  track  record  provides  the  DoD) 
with  a  high  confidence  level  that  new  technology  will  be  integrated  with  the  product, 
ensuring  a  leading  edge  end  product  for  their  HR  customers. 

The  DoD  should  identify  a  COTS  HR  provider  who  is  able  and  willing  to  participate 
in  a  proactive  partnership  with  DOD... 

Oracle  has  invested,  and  will  continue  to  invest,  millions  of  dollars  in  an  effort  to 
integrate  government  requirements  into  the  core  Oracle  HR  product.  Through  continual 
training,  workshops,  proofs  of  concept  and  briefings,  Oracle,  in  a  relatively  short  period 
of  time,  has  demonstrated  a  tangible  effort  at  partnership  and  joint  accountability  for  the 
success  of  the  COTS  HR  initiatives. 

The  DoD  should  initiate  the  expeditious  development  of  service  functional 
requirements  in  a  standard  repository  which  allows  for  easy  comparison  and  rapid 
determination  of  common  requirements,  (extension  of  JWG  process). 

Oracle  agrees  with  this  initiative.  Oracle  plans  to  integrate  DoD  common  requirements 
into  the  Oracle  HR  product.  It  is  incumbent  upon  the  DoD  to  agree  to  the  maximum 
amount  of  commonality,  thus  insuring  a  greater  level  of  COTS  product  capability. 
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Mr.  Larry  Rinderknecht  memo  with  EDS 
input  to  the  Defense  Science  Board  Task  Force 
on  Military  Personnel  Information  Management 
Report  -  BAFO,  (8/20/96) 
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EDS 


August  20, 1996 

Defense  Science  Board  Task  Force  Chairman  and  Executive:  Secretary,  Dr.  Salisbury  and  Ms 
Norma  St.  Claire 

From:  EDS  Military  Systems 

In  July's  meeting  of  the  Defense  Science  Board  (DSB)  Task  Force  on  Military  Personnel,  Dr. 
Salisbury  offered  the  opportunity  for  everyone  present  to  provide  "Brief  and  Final  Observations' 
on  the  recommendations  to  be  made  by  the  DSB  Task  Force. 

EDS  has  been  following  the  DSB  deliberations  since  February  when  we  made  a  presentation  to 
the  Board.  As  a  large  information  systems  integrator,  we  are  and  have  been  involved  in  many 
integration  efforts  similar  to  that  being  considered  by  the  DSB.  Of  these,  the  one  that  is  most 
comparable  to  the  DoD  in  terms  of  scope  and  complexity  is  our  integration  work  for  General 
Motors  (GM)  in  all  functional  areas  including  human  resources  and  payroll.  Those  efforts  began 
in  1984  and  are  continuing  today. 

Based  on  our  GM  experience,  and  that  with  other  clients  around  the  globe,  we  offer  comments  on 
three  Terms  of  Reference  (TOR)  of  the  DSB. 

TOR  1:  A  single,  fully  integrated  DoD  personnel/payroll  objective  system  for  2001 
(MPM  21). 

We  strongly  recommend  adoption  of  the  objective  of  having  a  fully,  integrated  DoD  personnel 
and  payroll  system  by  early  in  the  2000  decade. 

When  EDS  was  acquired  by  GM,  and  assumed  responsibility  for  all  of  GM’s  IT  personnel  and 
assets,  EDS  was  assigned  the  mission  of  supporting  GM's  production  of  world-class  quality 
vehicles,  while  containing  what  had  been  ever  increasing  IT  costs. 

Accomplishing  this  mission  in  GM  presented  special  challenges.  The  size  of  the  bureaucracy, 
the  fragmentation  of  efforts  across  different  divisions,  the  outdated  IT  infrastructure  of  many 
organizations,  the  lack  of  technical  talent  possessing  significant  functional  experience  and  the 
cost  were  factors  that  mitigated  against  an  immediate  integration  solution.  While  many  of  GM's 
systems  are  fully  integrated,  others  are  not. 

However  in  GM  integrated  systems  always  remained  the  objective,  simply  because  of  the  payoff 
in  large  resource  savings  and  enhanced  productivity.  Normally,  the  GM/EDS  team  worked 
first  to  establish  “best  practice"  business  processes  and  then  to  upgrade  and  fully  interface  GM's 
systems  and  infrastructure  before  tackling  an  integration  solution.  Payroll  is  a  notable  example 
as  full  integration  is  commencing  just  now. 
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Over  the  years  we  have  found  that  managing  expectations  was  the  singular  most  difficult  task 
since  integration  is  not  easily,  quickly  or  inexpensively  achieved. 

We  applaud  the  emerging  DSB  position  of  calling  for  a  common  core  as  the  right  first  step  to 
integrating  the  DoD’s  HR  and  payroll  systems.  Identification  of  a  common  core  should  begin 
with  an  in-depth  process  analysis  which  should  result  in  identification  of  a  common  core  of 
sufficient  size  to  enable  implementation  of  an  integration  solution  in  the  time  frame  mentioned. 

TOR  2:  A  COTS-based  solution  to  generate  savings. 

We  believe  a  COTS-based  solution  is  capable  of  generating  savings  for  DoD,  provided  careful 
limitations  on  scope  of  customizations  are  imposed. 

Our  experience  in  working  with  many  excellent  COTS  providers  is  that  there  simply  is  no  single 
COTS  package  that  will  totally  fit  any  corporate  or  government  set  of  requirements.  In  the 
case  of  the  DoD,  this  is  particularly  tnie  if  you  include  the  unique  characteristics  of  military 
manpower  and  tour  assignments  as  part  of  the  personnel  function/system.  Hence,  the  reality  for  a 
DoD  system  is  that  some  customization  must  occur.  The  issue  is  how  much?  Customization  of 
COTS  applications  cost  money.  If  the  customization  is  really  extensive,  it  can  make  acceptance 
of  subsequent  upgrades  of  the  COTS  product  prohibitively  expensive. 

To  be  worthwhile,  and  minimize  cost,  most  purveyors  of  COTS  solutions  would  tell  you  that  a 
COTS  package  must  meet  two  conditions  in  order  to  make  a  COTS  solution  a  viable  option  for 
the  organization  to  pursue: 

1)  As  a  generalized  rule  of  thumb,  the  package  must  have  an  inherent  "fit/gap" 
of  at  least  80/20%  to  the  current  business  processes,  or 

2)  the  "owners"  of  the  business  processes  must  be  willing  to  tailor  their 
processes  to  fit  the  COTS  package. 

It  should  be  recognized  that  customization  is  essentially  a  software  "tailoring"  effort  that  is  an 
iterative  process  involving  close  work  between  vendor  and  customer.  Even  when  done  right,  it  is 
not  a  speedy  process  and  may  take  months  or  even  years  to  complete  particularly  if  you  include 
upgrades. 

It  is  also  worthy  of  note,  that  issues  of  ownership  and  maintenance  of  the  "tailored"  software 
quickly  arise  and  need  to  be  openly  discussed  and  resolved  up  front.  Finally,  the  ability  of  any 
COTS  packages  to  handle  high  volume  processing  is  a  major  issue  that  we  faced  in  GM  and 
should  be  evaluated  for  a  very  large  customer  like  DoD. 
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TOR  3:  A  "generally  sound"  personnel  community  strategy  that  will  rely  on  "Executive 
Agents"  to  implement  the  objective  system  for  2001. 

We  believe  that  use  of  service  "Executive  Agents"  as  change  agents  to  implement  an  objective 
DoD  Personnel/Payroll  system  can  be  a  sound  strategy  provided  necessary  management 
controls  are  in  place  to  ensure  continuous  integration  throughout  the  systems  development/ 
implementation  period. 

Our  experience  in  GM  was  that  any  process  of  IT  integration/development  required  an 
"empowered"  change  agent  (one  having  authority,  responsibility  and  flnancial  control).  All 
lesser  degrees  of  managerial  control/coordination  yielded  deficient  results.  Ultimately  the 
EDS/GM  team  adopted  a  new  IT  systems  approval  process  to  ensure  continuous  integration  and 
continuous  revalidation  of  business  need  throughout  the  development  process.  This  process  is 
still  in  use  today. 

We  appreciate  that  operational  and  service  needs  may  dictate  a  less  centralized  management 
solution  within  DoD.  These  can  work,  but  will  require  much  tighter  integration  of  the  interfaces 
between  respective  systems  developed  under  the  auspices  of  different  “Executive  Agents"  or 
else,  as  GM  chose,  the  assignment  of  such  integration  responsibilities  to  a  third  party.  Our 
experience  is  that  the  requisite  level  of  integration  has  to  be  much  greater  than  the  mere 
specification  of  standards  or  declaration  of  a  generalized  common  operating  environment. 

EDS  actively  supports  the  efforts  of  the  DSB  Task  Force  and  stands  ready  to  assist  the  DoD  and 
the  Services  as  they  move  forward  to  defining  and  implementing  the  objective  Military  Personnel 
System  2001. 

EDS  appreciates  the  opportunity  to  share  these  thoughts  with  members  of  the  Board.  If  we  can 
provide  any  additional  information,  please  call  Deane  Stanley  or  Larry  Rinderknecht  at 
(703)  742- 1 679  or  742- 1651. 

Respectfully  submitted 


Herndon,  Virginia  22701 


Military  Systems  Division 
13600  EDS  Drive 
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APPENDIX  C:  TERMS  OF  REFERENCE 


This  USD  (A&T)  memorandum  dated  February  23,  1996  and  addressed  to  the  Chairman 
of  the  Defense  Science  Board  defines  the  Terms  of  Reference  for  the  Task  Force  on 
Military  Personnel  Information  Management. 
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THE  UNDER  SECRETARY  OF  DEFENSE 
3010  DEFENSE  PENTAGON 
WASHINGTON.  D.C.  20301-3010 


ACQUISITION  ANO 

technology 


Feb  23, 1996 


MEMORANDUM  FOR  CHAIRMAN,  DEFENSE  SCIENCE  BOARD 

SUBJECT:  Terms  of  Reference  -  Defense  Science  Board  Task  Force  on  Military  Personnel 
Information  Management 

You  are  requested  to  form  a  Defense  Science  Board  (DSB)  Task  Force  to  advise  the 
Secretary  of  Defense  on  the  best  automation  strategy  to  support  the  military  personnel  and  pay 
functions  for  all  active  and  reserve  components  throughout  the  Department. 

The  Military  Personnel  Information  Management  Task  Force  will  provide  advice, 
recommendations,  and  supporting  rationale  which  address  the  items  below. 

-  Assess  the  Department's  military  personnel  information  management  requirements  and 
determine  the  most  desirable,  feasible,  and  cost-effective  automation  solution:  for  instance, 
one  integrated  active/reserve  military  personnel/pay  system  or  multiple  interoperable  systems 
sharing  a  common  data  base. 


-  Assess  the  cost-effectiveness  of  adopting  and  reengineering  one  of  the  Service's  existing 
systems  as  the  standard  rather  than  initiating  new  development  that  may  take  advantage  of 
more  modem  technologies,  including  Commercial  Off  The  Shelf  (COTS)  applications. 

-  Evaluate  the  strategy  being  pursued  by  the  military  personnel  community  (OSD  and  the 
Services)  which  includes  defining  detailed  requirements  for  data,  interfaces,  and  functional 
processes  for  joint  military  personnel  information  management  and  designating  the  Navy  and 
Air  Force,  respectively,  as  Executive  Agents  for  the  design  and  development  of  field  and 
database  level  applications  which  would  support  core  requirements. 

-  Assess  the  strategy  for  dealing  with  Service  specific  systems  while  joint  military  personnel 
information  management  core  requirements  are  in  development. 

-  Determine  how  to  ensure  that  current  military  personnel  operations  are  not  interrupted  or 
compromised  in  any  way  that  would  interfere  with  DoD's  ability  to  mobilize  or  provide 
appropriate  support  to  military  personnel  and  veterans. 

The  Under  Secretary  of  Defense  (Personnel  and  Readiness)  and  the  Assistant  Secretary  of 

Defense  (Command,  Control,  Communications,  and  Intelligence)  will  jointly  sponsor  and 

provide  funding  for  the  Military  Personnel  Information-nation  Management  Task  Force,  Mr. 

Alan  Salisbury  will  serve  as  Chairman  of  the  Task  Force.  Ms.  Jeanne  Fites  and  Ms.  Cynthia 


Rand  will  serve  as  the  co-Executive  Secretaries.  LTC  T.  Van  Horn  will  be  the  Defense  Science 
Board  Secretariat  representative.  The  Office  of  the  Under  Secretary  of  Defense  (Acquisition  & 
Technology)  will  provide  funding  to  support  the  activities  of  the  DSB  members  on  the  Task 
Force. 


The  Military  Personnel  Information  Management  Task  Force  will  meet  at  least  monthly 
and  will  receive  initial  briefings  and  background  data  on: 

-  the  roles  and  responsibilities  for  the  Defense  Information  Management  Program; 

-  the  analyses  and  findings  of  the  Military  Personnel  Information  Management  efforts; 

-  descriptions  and  assessments  of  each  of  the  Services’  active  and  reserve  military  and  pay 
systems,  to  include  both  functional  and  technical  information; 

-  a  description  of  the  military  personnel  migration  strategy  and  efforts  to  define 
requirements  for  a  single,  integrated,  military  personnel  information  management  and  pay 
system. 

We  request  that  you  provide  a  report  August  31, 1996. 

This  Task  Force  will  be  operated  in  accordance  with  the  provisions  of  P.L.  92-463,  the 
"Federal  Advisory  Committee  Act,"  and  DoD  Directive  5104.5,  the  "DoD  Federal  Advisory 
Committee  Management  Program."  It  is  not  anticipated  that  this  Task  Force  will  need  to  go  into 
any  “particular  matters”  within  the  meaning  of  Section  208  of  Title  18,  U.S.  Code,  nor  will  it 
cause  any  member  to  be  placed  in  the  position  of  acting  as  a  procurement  official. 


Paul  G.  Kaminski 
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Appendix  D 

Recommendations  Mapped  to  Terms  of  Reference  Tasks 


A  brief  summary  of  recommendations  mapped  to  the  specific  questions  in  the 
Terms  of  Reference  is  provided  below.  (This  summary  is  intended  only  for  the  purpose 
of  supporting  the  mapping  of  the  questions  stated  in  the  Terms  of  Reference  to  the 
recommendations  and  discussion  in  the  main  body  of  the  report;  it  is  not  intended  that 
this  appendix  substitute  for  the  actual  recommendations  in  the  report.) 

1  -  Assess  the  Department's  military  personnel  information  management 
requirements  and  determine  the  most  desirable,  feasible,  and  cost-effective 
automation  solution:  for  instance,  one  integrated  active/reserve  military 
personnel/pav  system  or  multiple  interoperable  systems  sharing  a  common  data 
base. 

The  Task  Force  strongly  recommends  (Recommendation  A,  Section  IV)  that  the 
Department  move  to  a  single,  fully  integrated,  personnel  and  pay  system  with 
common  core  software  based  on  a  modified-COTS  solution.  This  objective 
system  should  incorporate  standard  data,  meet  all  DoD  technical  Common 
Operating  Environment  guidelines,  and  include  Service  specific  modules  as 
required  to  ensure  maximum  support.  Sections  El  and  IV  of  the  report  provide 
additional  details  on  the  objective  system,  a  recommended  path,  and  an 
organizational  structure  to  achieve  an  Initial  Operating  Capability  by  or  before 
2001. 

2  -  Assess  the  cost-effectiveness  of  adopting  and  reengineering  one  of  the 
Service’s  existing  systems  as  the  standard  rather  than  initiating  new  development 
that  may  take  advantage  of  more  modem  technologies,  including  Commercial  Off 
The  Shelf  (COTS)  applications. 

Although  the  Task  Force  members  did  not  have  the  time  to  perform  an  in-depth 
cost  analysis,  a  clear  consensus  was  reached  that  DoD  should  adopt  a  COTS- 
based  solution  rather  than  reengineering  one  of  the  existing  systems.  While  the 
objective  system  is  expected  to  generate  savings  associated  with  the  functional 
processes,  the  primary  functional  benefits  will  come  from  enhanced  performance 
and  support  to  Service  members. 

Recommendation  B,  Section  IV,  details  the  recommended  COTS  strategy.  In 
addition,  considerable  discussion  of  functional  and  technical  issues  related  to 
COTS  is  provided  in  Section  IE  (para  A.4.,  para  A.5.,  and  para  B.  1).  Costs  and 
potential  savings  are  addressed  in  Section  E  (para  B.). 

There  should  be  significant  savings  associated  with  the  development  and 
maintenance  of  a  common  system,  although  some  up  front  investment  is  required 
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and  savings  are  in  the  outyears.  Maintenance  savings  should  accrue  because  in 
the  future  there  will  be  a  need  to  maintain  and  update  a  single  system  instead  of 
many.  Even  greater  savings  will  be  realized  when  future  modernizations  are 
required,  since  all  future  modernizations  would  be  from  a  common  base. 

Technical  experts  pointed  out  that  even  if  functional  requirements  change  during 
the  development  process  there  are  great  technical  and  cost  advantages  associated 
with  creating  the  common  baseline  for  all  future  modifications.  Information 
provided  to  the  Task  Force  from  the  United  Kingdom  Personnel  Administration 
Agency  suggested  potential  cost  savings  of  up  to  thirty  per  cent  on  the 
maintenance  of  a  harmonized  personnel  and  pay  delivery  system.  Similarly,  the 
experiences  of  the  Marine  Corps  and  the  Air  Force  in  consolidating  and 
integrating  their  systems  demonstrate  expected  savings.  Additionally,  the  Navy 
Functional  Economic  Analysis  for  the  Navy  Standard  Integrated  Personnel  System 
also  projected  savings  associated  with  consolidation  and  integration. 

3  -  Evaluate  the  strategy  being  pursued  by  the  military  personnel  community 
(OSD  and  the  Services)  which  includes  defining  detailed  requirements  for  data, 
interfaces,  and  functional  processes  for  joint  military  personnel  information 
management  and  designating  the  Naw  and  Air  Force,  respectively,  as  Executive 
Agents  for  the  design  and  development  of  field  and  database  level  applications 
which  would  support  core  requirements. 

Recommendation  B,  Section  IV,  addresses  this  issue.  Basically,  the  Task  Force 
believes  that  the  general  strategy  of  the  personnel  community  is  sound,  but  must 
be  accelerated  to  meet  a  timeline  that  has  relevance  for  the  Department.  System 
functional  requirements  must  be  defined  in  a  Joint  environment,  with  full 
participation  from  the  Services,  the  Joint  Staff,  and  OSD.  The  USN  and  USAF 
agreed  that  they  would  accept  the  roles  of  Executive  Agents  for  the  objective 
system.  The  Marine  Corps  representatives  in  the  Joint  Requirements  and 
Integration  Office/Joint  Working  Group  should  play  the  lead  role  in  defining  the 
functional  requirements  for  effective  integration  of  personnel  and  pay. 

4-  Assess  the  strategy  for  dealing  with  Service  specific  systems  while  joint 
military  personnel  information  management  core  requirements  are  in 
development. 

Recommendation  C,  Section  IV,  directly  addresses  the  transition  strategy. 

The  fielding  of  SIDPERS-3  should  continue  as  planned  within  the  Army.  The 
Navy  accepted  the  challenge  to  focus  on  the  objective  system,  integrating  the 
development  of  deployment  of  critical  NSIPS  and  NMPDB  capabilities  into  the 
objective  system  program,  and  agreed  to  continue  as  Executive  Agent  for  the  field 
system.  The  Air  Force  agreed  to  the  role  of  Executive  Agent  for  the  corporate  tier 
and  system  architecture.  Ongoing  and  planned  Air  Force  and  USMC 
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modernization  efforts  will  also  be  refocused  on  the  objective  system.  In  short,  all 
planned  new  modernization  efforts  should  be  refocused  on  the  objective  system. 

5  -  Determine  how  to  ensure  that  current  military  personnel  operations  are  not 
interrupted  or  compromised  in  any  wav  that  would  interfere  with  DoD’s  ability  to 
mobilize  or  provide  appropriate  support  to  military  personnel  and  veterans. 

This  is  also  addressed  in  Recommendation  C,  Section  IV. 

The  Task  Force  reviewed  with  each  of  the  Services  their  thoughts  on  individual 
transition  strategies.  Detailed  transition  plans  should  be  prepared  by  each  Service 
by  September  30, 1997.  Consistent  with  the  roles  and  strategies  indicated  in  items 
2, 3,  and  4  above,  individual  transition  plans  for  the  Services  should  allow  for 
continuity  of  support  until  the  objective  system  is  available. 
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